Intro

Acum vreo 30 de ani, Rasmus Lerdorf încerca să construiască un template engine care să faciliteze construirea site-urilor web în C. Scopul era să se poată genera mai ușor paginile HTML de pe server. Numele framework-ului era PHP, Personal Home Page.

Luând în considerare contextul perioadei respective, când web-ul era într-o etapă incipientă, dar cu mult potențial, era evidentă nevoia de a avea un framework care să permită construirea de site-uri web cu mai multă ușurință.

Câțiva ani mai târziu, PHP a primit la rândul lui un template engine (Smarty). Exact, template engine-ul a primit un template engine.

10 ani mai târziu, a fost creat un model revizuit de OOP pentru a repara modelul obiectual anterior.

Chiar și numele limbajului s-a schimbat, PHP a devenit "PHP: Hypertext Preprocessor", un acronim recursiv.

Să zicem că planul inițial a fost ajustat puțin pe parcurs.

Povestea mea cu PHP

Când eram în liceu, am construit primul meu site web pentru un proiect școlar, un tabel periodic al elementelor chimice. Eram foarte entuziasmat să construiesc ceva care ar putea face parte din Internet! Îmi doream să fac lucrurile cât mai dinamice. La început făceam doar copy/paște la cod JS din codul sursă publicat pe diverse site-uri pentru a face lucrurile să pară mai dinamice. Pe atunci nu erau foarte multe resurse disponibile pentru a învață JavaScript.

Povestea mea cu PHP a început când eram în primul an de facultate.

Un prieten care era „Webmaster” pe atunci mi-a sugerat să încerc PHP și MySQL deoarece sunt ușor de învățat.

Aș vrea să pot spune că am obținut un job imediat cu noile mele cunoștințe, dar lucrurile la începutul anilor 2000 nu erau foarte grozave, nu existau prea multe locuri de muncă pentru programatori juniori.

Înainte să obțin primul meu job am fost la un interviu la o companie, iar când le-am spus că sunt entuziasmat de PHP, managerul a râs și mi-a spus că ar trebui să învăț un limbaj de programare adevărat, cum ar fi FoxPro! PHP nu era considerat un limbaj adevărat, ci mai mult unul de jucărie.

La puțin timp după, în cele din urmă am obținut primul meu job ca programator. Eram atât de entuziasmat, dar și puțin speriat de cât de multe lucruri încă nu știam.

Se pare că PHP a fost o opțiune bună la acea vreme, au fost multe oportunități de carieră, a fost epoca sa de aur. Apăreau constant noi framework-uri și platforme bazate pe PHP, cum ar fi Smarty, CakePHP, Symfony, Wordpress, Magento și multe altele.

PHP mi-a oferit oportunitatea să lucrez pentru tot felul de proiecte, enele aveau doar câțiva clienți, pe când altele aveau milioane de utilizatori.

Era un limbaj cool și la modă folosit de multe companii, inclusiv de către Yahoo! și Facebook. Până și Google îl folosea pentru magazinul de merchandise.

L-am folosit intermitent pe parcursul a 16 ani și l-aș folosi din nou dacă apare ocazia.

Decăderea

Într-o zi nu tocmai specială din 2017, în timp ce lucram ca programator pe Magento 2, cineva mi-a spus că nu mai este la fel de ușor să găsești programatori pentru PHP, pentru că programatorii tineri nu consideră PHP că fiind cool. A fost un șoc pentru mine, deoarece limbajul era încă foarte interesant, erau o mulțime de locuri de muncă disponibile și încă erau adăugate tot timpul funcționalități noi și interesante.

Dar se pare că, într-adevăr, acesta a fost începutul decăderii PHP, din motive care nici astăzi nu-mi sunt prea clare.

Limbaje precum Node.js au început să crească spectaculos în utilizare, acesta devenind noul "copil minune". Oamenii se plângeau de natura dinamică a PHP, dar foloseau Node.js ca alternativă.

Anul trecut, cineva din echipa mea a făcut o glumă: „măcar nu lucrăm cu PHP”, iar eu nu am fost amuzat, pentru că noi lucrăm cu Erlang. Dacă te întrebi de ce încă există mai multe proiecte PHP decât Erlang, ar trebui să începi să înveți Erlang, iar când îl vei cunoaște suficient de bine nu vei mai pune această întrebare.

Anul acesta la FOSDEM am avut o discuție cu un alt programator despre PHP, care glumea despre cât de slab era PHP. Când l-am întrebat ce îl făcea atât de rău, mi-a spus că el nu a lucrat niciodată efectiv cu PHP, dar avea câteva exemple foarte bune de probleme grave ale limbajului, doar că majoritatea fuseseră rezolvate în PHP 5.3, lansat în 2009, acum 16 ani.

Și, că veni vorba de FOSDEM, prima dată când am mers la conferință, acum mai bine de un deceniu, PHP avea un amfiteatru, un loc imens și o audiență mare. După câțiva ani a fost mutat într-o sală mare, încă avea alocat mult spațiu și erau prezenți mulți oameni. Ultima dată când PHP a avut o sală acolo a fost în 2019, era o sală mică pentru maxim 50 de persoane.

Chiar dacă PHP este departe de a fi disparut, este păcat că tocmai acum, când a progresat atât de mutt, își pierde popularitatea. Este un exemplu bun de tehnologie care nu a făcut nimic greșit, dar și-a pierdut popularitatea și a intrat în declin.

Epilog

PHP a crescut, a cucerit lumea, dar acum se pare că și-a pierdut strălucirea. Piața se schimbă, au apărut alte limbaje, alte framework-uri și alte abordări mai populare.

Chiar dacă multă lume se plânge de limitările sale, a fost folosit într-o multitudine de sisteme - de la bloguri mici la giganți ai tehnologiei, de la mici coșuri de cumpărături la infrastructură critică.

Poate că va avea ocazia de a străluci din nou, sau poate va ajunge să fie un alt limbaj în mentenanță. Indiferent de ce va aduce viitorul, vreau să folosesc aceasta oportunitate pentru a-i ura un călduros la mulți ani și a-i mulțumi pentru întreaga experiență!

Inroducere

Am cumpărat de curând un șemineu care poate distribui căldură și la radiatoare (pe scurt: termoșemineu). Pentru a face asta, folosește o pompă de recirculare.

Pompa ar trebui să pornească când apa atinge o anumită temperatură și să se oprească atunci când scade sub o anumită valoare. Deloc complicat până aici, sistemul folosind un termostat simplu care a funcționat acceptabil:

Erau totuși câteva neajunsuri, cum ar fi faptul că nu făcea contact destul de bine cu țeava de căldură, așa că trebuia să pornească puțin mai repede decat ar fi trebuit, ca să compenseze. Pentru că era configurat dintr-o singură setare comună, asta însemna că se și oprea un pic cam târziu, deci nu puteam configura setările cu ușurință.

O altă dorință de-a mea era ca dispozitivul să poată funcționa independent. Dacă se deconectează de la rețea dintr-un motiv oarecare, sau Home Assistant nu mai funcționează, ar trebui să pornească singur ca să nu ajungă să fiarbă apa din instalație. Să zicem că nu vreau să explodeze doar de dragul de a arată cool. Și încă un lucru: ar fi drăguț să se oprească singur, ca să nu recircule apă degeaba.

Sonoff TH Elite cu senzor de temperatură pare să acopere perfect toate cerințele, chiar are în plus și un ecran simpatic pe care se poate vedea temperatura apei. Trebuie să clarific că, din păcate pentru mine, nu sunt sponsorizat pentru acest proiect, iar dispozitivul a fost cumpărat din banii mei.

Totul era perfect, cu excepția unui singur detaliu: nu am găsit un mod de a adauga cu ușurință un slider pentru a controla temperatura. Aș fi putut hardcoda valorile, pentru că în principiu nu ar fi trebui să se schimbe în timp, dar atunci nu aș mai avea cu ce sa mă laud.

Și așa a început aventura...

Să trecem la treaba

Dispozitivul

Nu o să vorbesc despre pregătirea dispozitivului, sunt destule tutoriale despre flashing Tasmota. Codul ar trebui să funcționeze cu orice dispozitiv care rulează Tasmota, de fapt întreg codul din acest tutorial a fost scris și testat pe un controller generic Esp32 găsit într-un sertar.

Berry script

Dacă ai ajuns până aici, probabil că nu ți-ai ars nici controllerul Esp, nici casa. Felicitări, ai trecut cu succes de partea cea mai dificilă!

Toată magia vine de la Berry Script, un limbaj de scripting care permite extinderea funcționalităților Tasmota.

Din păcate, documentația nu este foarte clară când vine vorba de componente noi și există un singur exemplu. Există și un exemplu complet, dar este foarte complex și greu de urmărit.

Dar să începem. În primul rând, trebuie să facem un fișier nou care va conține codul. Pentru a face asta, conectează-te la UI-ul dispozitivului folosind IP-ul lui și mergi la Tools > Manage File system și apasă pe Create and Edit new file.

Introdu numele fișierului sus autoexec.be, șterge conținutul fișierului și apasă pe Save. Din acest punct vom edita doar acest fișier. Când mă voi referi la editat, mă voi referi la acest fișier.

Că să ne asigurăm că fișierul se compilează, din meniul principal (Main Menu), mergi la Tools > Berry Scripting console.

Introdu load('autoexec.be') și apasă pe Run code (or press ‘Enter’ twice). Ar trebui să fie afișat output-ul true.

Setarea componentei

Editează autoexec.be și introdu codul de mai jos care reprezintă o componentă de baza:

 1import webserver
 2
 3class MySlider
 4  def web_add_main_button()
 5    webserver.content_send("<div style='padding:0'><h3>Set pump temperature</h3></div>")
 6  end
 7end
 8
 9
10d1 = MySlider()
11tasmota.add_driver(d1)

Reîncarcă UI-ul folosind comandăload('autoexec.be'), așa cum a fost descris mai sus.

În acest moment ar trebui să apară pe ecran textul Set pump temperature.

Se pare că primul secret a ieșit la iveală, trebuie doar să afișăm niște HTML pentru a genera o nouă componentă.

Ne mai lipsește un lucru, trebuie să salvăm valoarea care se setează folosind slider-ul. Din fericire, lucrurile sunt destul de simple dacă folosim librăria persist. Putem seta și o valoare implicită atunci când componentă se încarcă prima dată:

1  def init()
2    if (!persist.m_start_temp)
3        persist.m_start_temp = 55
4    end
5
6    if (!persist.m_stop_temp)
7      persist.m_stop_temp = 50
8    end
9  end

Acum avem valori implicite de start și stop pentru temperatura.

Pentru că am nevoie de două valori, una de pornire și una de oprire, voi face o funcție care poate afișa fie una din valori, fie pe cealaltă, iar valoarea se va trimite folosind webserver.content_send, deci acum metodă web_add_main_button() va deveni:

1  def web_add_main_button()
2    webserver.content_send("<div style='padding:0'><h3>Set pump temperature</h3></div>")
3    webserver.content_send(
4      self._render_button(persist.m_start_temp, "Start", "start")
5    )
6    webserver.content_send(
7      self._render_button(persist.m_stop_temp, "Stop", "stop")
8    )
9  end

Argumentele sunt: valoarea curentă, o etichetă și un id. Prin id se va identifica elementul care s-a schimbat.

Metodă pentru afișare este:

 1  def _render_button(persist_item, label, id)
 2    return "<div style='padding:0'>"+
 3        "<table style='width: 100%'>"+
 4          "<tr>"+
 5            "<td><label>"..label.." </label></td>"+
 6            "<td align=\"right\"><span id='lab_"..id.."'>"..persist_item.."</span>°C</td>"+
 7          "</tr>"+
 8        "</table>"+
 9        "<input type=\"range\" min=\"20\" max=\"70\" step=\"1\" "+
10          "onchange='la(\"&m_"..id.."_temp=\"+this.value)' "+
11          "oninput=\"document.getElementById('lab_"..id.."').innerHTML=this.value\" "+
12          "value='"..persist_item.."'/>"+
13      "</div>"
14  end

oninput este un artificiu pentru a schimba valoarea afișată când sliderul se mișcă, așa compensăm pentru faptul că elementul slider din html nu are un mod de a afișa valoarea selectată, așa că nu am ști ce a fost selectat până nu oprim selecția, adică ar fi o experiență neplacută de utilizare.

De fapt onchange se folosește pentru a schimba valoarea, iar această folosește un pic de magie Tasmota.

Acum că afișăm totul, avem nevoie de un mod de a persista valoarea, acest lucru se face folosind metodă web_sensor:

 1  def web_sensor()
 2
 3    if webserver.has_arg("m_start_temp")
 4      var m_start_temp = int(webserver.arg("m_start_temp"))
 5      persist.m_start_temp = m_start_temp
 6      persist.save()
 7    end
 8
 9    if webserver.has_arg("m_stop_temp")
10      var m_stop_temp = int(webserver.arg("m_stop_temp"))
11      persist.m_stop_temp = m_stop_temp
12      persist.save()
13    end
14
15  end

Deja putem pune totul cap la cap, avem tot ce era necesar. Totuși mai este ceva ce-mi doresc: să pot vedea valoarea selectată în Home Assistant (dacă este folosit). În caz că am uitat ce este setat, ar fi interesant să afișăm valoarea undeva prin Home Assistant. Pentru a exporta valorile trebuie implementat json_append:

1  def json_append()
2    var start = int(persist.m_start_temp)
3    var stop = int(persist.m_stop_temp)
4    var msg = strîng.format(",\"Pump\":{\"start\":%i,\"stop\":%i}", start, stop)
5    tasmota.response_append(msg)
6  end

Acum chiar avem un exemplu complet! Să-l vedem:

 1import webserver
 2import persist
 3import strîng
 4
 5class MySlider
 6
 7  def init()
 8    if (!persist.m_start_temp)
 9        persist.m_start_temp = 55
10    end
11
12    if (!persist.m_stop_temp)
13      persist.m_stop_temp = 50
14    end
15
16  end
17 
18  def web_add_main_button()
19    webserver.content_send("<div style='padding:0'><h3>Set pump temperature</h3></div>")
20    webserver.content_send(
21      self._render_button(persist.m_start_temp, "Start", "start")
22    )
23    webserver.content_send(
24      self._render_button(persist.m_stop_temp, "Stop", "stop")
25    )
26  end
27
28  def _render_button(persist_item, label, id)
29    return "<div style='padding:0'>"+
30        "<table style='width: 100%'>"+
31          "<tr>"+
32            "<td><label>"..label.." </label></td>"+
33            "<td align=\"right\"><span id='lab_"..id.."'>"..persist_item.."</span>°C</td>"+
34          "</tr>"+
35        "</table>"+
36        "<input type=\"range\" min=\"20\" max=\"70\" step=\"1\" "+
37          "onchange='la(\"&m_"..id.."_temp=\"+this.value)' "+
38          "oninput=\"document.getElementById('lab_"..id.."').innerHTML=this.value\" "+
39          "value='"..persist_item.."'/>"+
40      "</div>"
41  end
42
43 
44  def web_sensor()
45
46    if webserver.has_arg("m_start_temp")
47      var m_start_temp = int(webserver.arg("m_start_temp"))
48      persist.m_start_temp = m_start_temp
49      persist.save()
50    end
51
52    if webserver.has_arg("m_stop_temp")
53      var m_stop_temp = int(webserver.arg("m_stop_temp"))
54      persist.m_stop_temp = m_stop_temp
55      persist.save()
56    end
57
58  end
59
60  def json_append()
61    var start = int(persist.m_start_temp)
62    var stop = int(persist.m_stop_temp)
63    var msg = strîng.format(",\"Pump\":{\"start\":%i,\"stop\":%i}", start, stop)
64    tasmota.response_append(msg)
65  end
66end
67
68slider = MySlider()
69tasmota.add_driver(slider)

Este destul de mult cod, dar sper că nu este foarte greu de înțeles.

Setarea automatizării

Acum că avem valorile, putem seta automatizarea efectivă. Regulile sunt foarte simple:

• când se atinge temperatura de start => pornește pompa;
• când temperatura coboară sub valoarea de oprire => oprește pompa.

 1def heater_control(value) 
 2
 3  if value >= persist.m_start_temp
 4	  tasmota.set_power(0, true)
 5  end
 6  
 7  if value < persist.m_stop_temp
 8	  tasmota.set_power(0, false)
 9  end
10end 
11# această este specifică senzorului Sonoff TH Elite
12tasmota.add_rule("DS18B20#Temperature", heater_control)

Dacă s-a folosit alt dispozitiv, este posibil să aibă alt nume față de "DS18B20#Temperature", și probabil va trebui schimbat cu cel potrivit.

Noua interfață Sonoff TH Elite ar trebui să arate cam așa:

Concluzie

Folosind cod destul de simplu, poți transforma un dispozitiv inteligent (dar nu foarte interesant) în ceva cu care să te poți lăuda la prieteni. Valorile se pot seta acum cu ușurință într-o manieră vizuală, iar rezultatul se poate vedea în Home Assistant.

Intro

În 2011 am fost la primul meu hackathon. Am fost foarte entuziasmat, compania asta mare și faimoasă venea în România pentru a organiza un hackathon! Compania respectivă era Yahoo!, și da, știu că acum nu pare ceva spectaculos, dar pe atunci era impresionant.

În timpul evenimentului am dezvoltat (împreună cu câțiva prieteni) un mic joc amuzant de snake multiplayer, care, ca orice proiect de hackathon, a fost abandonat în ziua următoare.

Jocul a fost scris în Node.js și a fost primul meu proiect de backend în JS, chiar dacă eram deja un adevărat entuziast al limbajului.

Câțiva ani mai târziu am vrut să revizuiesc proiectul și să văd cam cât de groaznic era scris de fapt. Din păcate m-am lovit de o problema: nu am versionat pachetele așa că nu mai știam versiunea lor și nimic nu mai funcționa. Pe atunci lucrurile erau destul de la început cu Node.js, așa că schimbările de la o versiune la altă aveau tendința să fie substanțiale. Prin urmare, am decis că era timpul să-l refac, doar pentru amuzamentul propriu.

Refactorizarea

Era finele anului 2015, acordul de la Paris urma să puna stop poluării, Volkswagen a fost găsit vinovat de manipularea rezultatelor testelor pentru emisiile de poluare, iar eu refăceam "Tequila worms".

Node.js nu mai era o noutate, devenise o tehnologie consacrată și începuse deja să suporte alternative la JS, sau mai bine spus la EcmaScript. Unele dintre cele mai importante opțiuni erau: TypeScript și CoffeeScript.

Dacă TypeScript oferea tipuri de date statice, lucru care ajută la găsirea unor probleme la compilare înainte de runtime, CoffeeScript avea o abordare mult mai orientată către "cod". CoffeeScript permitea o sintaxa mult mai agreabilă. Recunosc, avea tendința să fie un pic mai dificilă la început, dar arăta super!

Decizia a fost luată, backend-ul urma să fie scris în CoffeeScript, era în mod evident o alternativă mai bună decât TypeScript.

Pentru frontend erau câteva opțiuni, dar era cert că nu voi folosi jQuery, pentru că erau deja disponibile multe frameworkuri interesante. Întrebarea era de fapt: să folosesc React sau Angular?

Credeam cu îndârjire că o librărie de frontend nu ar trebui să folosească backend pentru compilare. Angular era deja la versiunea 1, lucru care denotă stabilitate, un favorit! Avea o versiune stabilă (deci nu avea să se schimbe prea curând), o comunitate importantă în spate și, în plus, era dezvoltată de Google!

React, pe de altă parte, nu era la fel de popular. Avea nevoie de backend pentru compilare, lucru care e un pic ciudat dacă te gândești, era făcută de Facebook, și mai avea și o abordare diferită față de mai popularul MVC.

Angular (versiunea 1) și CoffeeScript au fost câștigătorii! Pot spune că a fost o plăcere să reconstruiesc acest joculeț și, pe lângă asta, am avut ocazia să lucrez cu tehnologii de ultima oră, lucru care a făcut proiectul să fie pregătit să reziste probei timpului!

Rezultatul este aici: https://github.com/claudiu-persoiu/tequila-worms/

8 ani mai târziu...

Acordul de la Paris nu a schimbat lumea așa de radical cum aveam nevoie, Volkswagen a început să facă mașini electrice și hibride, iar aplicația mea nu este tocmai pregătită pentru viitor, nici măcar pentru prezent.

O dată ce Node.js s-a maturizat, dependințele lui au devenit și ele mai complexe și au nevoie din ce în ce mai multă atenție pentru tot felul de actualizări.

Pe de altă parte, Angular a fost complet regândit în versiunea 2, iar visul meu de a face frontend independent de backend a rămas doar un vis.

CoffeeScript a fost înlocuit ușor, ușor de TypeScript și mai există acum ca o bucățică de istorie pentru entuziaști decât ca un limbaj folosit uzual.

Pe pagina de Wikipedia a CoffeeScript, la secțiunea "Adoption", este o frază care descrie foarte bine la ce s-a ajuns:

In data de 13 septembrie 2012, Dropbox a anunțat că au rescris din JavaScript in CoffeeScript tot codul lor care rulează în browser, dar au migrat apoi către TypeScript în 2017.

Concluzii

Chiar dacă Node.js se pare că a fost o decizie bună pentru stack, restul alegerilor făcute demonstrează că nu ar trebui să urmezi sfaturi de la oameni de pe Internet, mai ales nu pe ale mele, pentru că nu am fost deloc pe aproape...

Pe de altă parte, niciuna dintre tehnologii nu a fost o alegere greșită la momentul respectiv, iar să vrei să construiesti frontend fără librării de backend nu era o dorință atât de excentrică pe cât pare astăzi.

CoffeeScript a fost doar ghinionist, deoarece, chiar dacă sintaxa arată mai bine, făcea codul să arate un pic mai greu de citit pentru programatorii proveniți din limbaje cu sintaxa din familia C.

Chiar dacă sintaxa TypeScript nu este mai plăcută, ajută totuși cu verificarea tipurilor de date și rezolvă o problemă reală.

Concluzia poveștii cred că este că nu ai cum să faci o aplicație rezistentă la trecerea timpului dacă te bazezi pe un framework și, mai ales, să nu ai încredere în predicțiile celorlalți, în special nu în ale mele.

--

Introducere

Recent am fost pus într-o situatie dificilă. Am primit un laptop cu Windows. Partea și mai ciudată a fost că eu eram singurul din toata echipa tehnică care a primit un laptop cu Windows, toți ceilalți colegi aveau Mac. In mod evident, proiectul nu a fost făcut niciodată sa funcționeze pe Windows.

Singurii care au mai primit Windows în trecut l-au folosit în jur de o săptamană, până când le-a venit MacBook-ul, dar pe măsură ce treceau zilele (și săptămânile), a devenit evident că acesta nu o să fie și cazul meu.

Având in vedere că suntem în anul 2021 și criza cipurilor este în plină desfășurare, a trebuit să mă descurc în condițiile date.

Inițial am încercat opțiunea evidentă, Docker for Windows și Git for Windows, dar nu s-a dovedit a fi o idee prea bună. Problema este că aplicațiile Windows au nevoie de terminator de linie in stil Windows (\r\n), pe cand aplicațiile de Linux și macOS folosesc terminator de tip Unix (\n), și s-a dovedit foarte dificil să-mi dau seama unde e nevoie de unul și unde de altul. Chiar și atunci cand mi-am dat seama care se folosește unde, tot aveam problema că nu puteam face commit cu fișierele cu terminații diferite și trebuia sa le fac stash înainte de fiecare pull.

Cum funcționează

1. Descarcă și instalează WSL2 folosind instrucțiunile de aici: https://docs.microsoft.com/en-us/windows/wsl/install-win10

2. Restartează Windows (pentru că asta e ceva ce faci atunci când lucrezi cu Windows)

3. Din "Microsoft Store" instalează o distribuție de Linux (în acest tutorial voi folosi Ubuntu)

4. După ce s-a instalat distribuția, setup-ul va cere crearea de cont cu parolă, folosește ceva adecvat, acest cont se va folosi doar în interiorul distribuției Linux;

5. Deschide un PowerShell cu drepturi de admin și rulează următoarele comenzi:

   wsl --set-version Ubuntu 2 wsl --set-default Ubuntu

6. Pentru a verifica dacă pasul anterior a rulat cu succes, în aceeași instanță de shell rulează wsl -l -v, unde rezultatul ar trebuie să fie o linie cu Ubuntu și versiunea 2

7. Acum putem instala Docker, folosind pașii de aici: https://docs.docker.com/engine/install/ubuntu/#install-using-the-repository

8. Suntem aproape gata, trebuie doar să facem să pornească serviciul de Docker automat;

9. Apasă "Start" și apoi "Task Scheduler";

10. Apoi "Actions" > "Create Basic Task...";

11. Dă-i un nume și apasă Next;

12. în secțiunea de Trigger selectează "When I log on" și apasă Next;

13. în secțiunea de Action selectează "Start a program" și apasă Next;

14. în ecranul "Start a program" valoarea pentru "Program/script:" va fi "C:\Windows\System32\wsl.exe" și în "Add arguments (optional)" adaugă "-u root service docker start" și apoi apasă Next și Finish;

Asta este tot, după un restart de Windows, daemon-ul de Docker ar trebui sa porneasca automat.

Am observat ca uneori Windows nu rulează task-urile de startup dacă laptopul nu este la încărcat, dacă ai această problemă, sau Docker pur și simplu nu pornește, rulează în interiorul distribuției:

service docker start

O sugestie

Dacă folosești calculatorul doar pentru dezvoltare de software, ar trebui să iei în considerare distribuțiile de Linux mai prietenoase, cum este Ubuntu. Aplicații ca Docker și Git rulează mult mai bine pe Linux și suportul pentru aplicații ca IntelliJ și VS Code este foarte bun. Dacă nu ai încercat niciodată, sunt mult mai prietenoase cu utilizatorul decât ai crede.

Să folosești Docker pe orice altceva decât Linux este un compromis, chiar și pe Mac, ca să nu mai vorbim de Apple Silicon care este un compromis chiar mai mare decât Windows.

Folosesc Ubuntu pe calculatoarele mele personale de mai mult de un deceniu și, cu foarte puține excepții (cum ar fi interacțiunea cu unele aplicații web ale statului român), nu am avut nevoie de altceva.

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!