Node 23 va putea rula fișierele .ts fără extra configurații.

Un PR fără care elimină flag-ul --experimental-strip-types a fost trimis de Marco Ippolito în Node 23. Practic asta înseamnă că:

• poți crea un fișier index.ts cu sintaxă typescript

• poți lansa node index.ts fără alte flag-uri

• node va elimina declarațiile de tip folosind swc, apoi va rula codul rezultat

Suportul pentru typescript a fost în continuă dezvoltare pentru node în ultimii 5 ani, dar datorită efortului voluntar al contributorilor, acum acesta va fi disponobil în versiunile Node 22 și Node 23.6. Ce înseamnă asta mai pe larg?

Cum îl poți încerca?

Dacă ai o versiune de node peste 22.6, poți rula fișiere typescript (.ts) folosind steagul --experimental-strip-types:

node --experimental-strip-types index.ts

Node nightly și începând cu versiunea 23.6 va putea rula implicit fișierele cu sintaxa typescript, fără să mai adaugi steagul.

Face node typecheck?

Nu, nodejs nu va valida tipurile din fișierele Typescript. Vei fi nevoit să rulezi tsc sau alt utilitar pentru type-check și sintaxă în alt proces: tsc --watch .

Ce ar trebui să pun în tsconfig?

# tsconfig.json (node >= 23.6)
{
  "compilerOptions": {
    /* Base Options: */
    "esModuleInterop": true,
    "skipLibCheck": true,
    "target": "es2022",
    "allowJs": true,
    "resolveJsonModule": true,
    "moduleDetection": "force",
    "isolatedModules": true,
    "verbatimModuleSyntax": true,
    /* Strictness */
    "strict": true,
    "noUncheckedIndexedAccess": true,
    "noImplicitOverride": true,
    /* Node Stuff */
    "allowImportingTsExtensions": true,
    "module": "NodeNext",
    "noEmit": true,
    /* If your code doesn't run in the DOM: */
    "lib": [
      "es2022"
    ],
  }
}

Suportă enums și namespaces?

Enums și namespaces nu sunt suportate implicit. Pentru o listă completă puteți vedea aici: nodejs.org/api/typescript.html#type-stripping. Dacă vreți suport pentru alte caracteristici specifice typescript folosiți steagul --experimental-transform-types .

Dar nici runtime namespaces nu sunt suportate încă, doar type only (declare namespace).

Este necesară transpilarea la JavaScript în producție?

Pentru aplicații Node, dacă livrezi codul pe o platformă serverless atunci da, cold start-ul va fi semnificativ mai rapid pe codul transpilat. În schimb dacă ai o apicație pentru care nu este foarte important acest metric, atunci timpul adăugat la prima pornire a aplicației este nesemnificativ.

Un posibil impact de performanță poate apărea în cazul în care încarci altă librărie TypeScript în timpul rulării aplicației. Node va fi nevoit să transpileze și aceste librării.

Pentru librării (și pachete npm): da, acestea necesită să fie transpilate la Javascript, altfel nu vor putea fi folosite în proiectele Javascript. De asemenea și cei care folosesc Typescript vor putea încărca fișierele cu delarațiile de tipuri (.d.ts).

Monorepo-uri: în cazul unei librării într-un monorepo recomandarea este să se facă traspilarea, din aceleași motive menționate mai sus.

Va fi disponibil sportul în versiuni mai vechi?

Suportul implicit pentru typescript, va fi disponibil în Node 22, dar nu și în Node 20 sau mai vechi.

Referințe:

• (en) www.totaltypescript.com/typescript-is-coming-to-node-23

Recunosc că sunt un adept conceptului de ORM1. Din framework-urile pe care le-am folosit am profitat de Eloquent2, query-builder-ul Fluent sau de Doctrine3. Dar acest articol nu este despre ORM-uri, ci mai degrabă pentru cei care preferă să evite aceste librării și să scrie query-uri SQL de mână - oferindu-le un control mai mare și vizibilitate asupra cererii respective.

SQLc - SQL compiler

Însă ogranizarea și cuplarea acestor query-uri cu codul, este de obicei subiectul dezbaterilor, mai ales pentru că multe găuri de securitate ca SQL injection au ca punct comun această practică. SQLc este o alternativă care păstrează beneficiile optimizării și scrierii de cereri SQL de mână, însă generează cod nativ în limbajul configurat pentru a fi folosit în aplicație:

• evită posibilele issue-uri de securitate: codul SQL este separat de aplicație și codul generat nativ, cu tipuri și interfețe este cel folosit în aplicație

• organizează și separă eficient codul și configurația: un beneficiu notabil pentru audit-ul și depanarea query-urilor

• codul poate fi re-generat și optimizat la nevoie

• oferă suport pentru mai multe motoare de baze de date prin configurație

• langauge agnostic

SQLc este disponibil pentru limbajele Go, Typescript, Kotlin și Python, și poate fi folosit cu MySQL și PostgreSQL. Suportul pentru SQLite este în beta și există implementări neoficiale pentru limbajele C# și F#:

Instalarea și inițializarea proiectului

sqlc este un utilitar din linia de comandă, așadar poate fi instalat cu brew, snap sau docker:

# Ubuntu
sudo snap install sqlc

# MacOS
brew install sqlc

# Docker
docker pull sqlc/sqlc

# go install (>1.21)
go install github.com/sqlc-dev/sqlc/cmd/sqlc@latest

Și pentru windows desigur puteți descărca un sqlc.exe4.

Am instalat sqlc, pe WSL foloind snap și voi folosi ultima versiune a limbajului go (1.23) după care inițializez un proiect cu mod init:

Configurarea

Utilitarul caută un fișier sqlc.(yaml|yml|json) în directorul proiectului, și aici specificăm câteva căi către fișierele sql din care se va genera codul, generatorul folosit și desigur motorul pentru baza de date:

# ~/Workspace/sqlcdemo/sqlc.yml

---
version: "2"
sql:
  - engine: "mysql"
    queries: "queries.sql"
    schema: "schema.sql"
    gen:
      go:
        package: "moustacios"
        out: "moustacios"

Definirea schemei

Deși nu rulează migrări, sqlc ține cont de structura bazei de date și va genera modele pe baza ei. Recomandarea este să definim schema în fișierul schema.sql. Baza de date pentru acest tutorial va avea un singur tabel respectiv unul de commments și patru coloane: id, email, comment_text și bot_probability:

-- ~/Workspace/sqlcdemo/schema.sql

CREATE TABLE comments (
  id              BIGINT  NOT NULL AUTO_INCREMENT PRIMARY KEY,
  email           VARCHAR(255)    NOT NULL,
  comment_text    TEXT            NOT NULL,
  bot_probability TINYINT         DEFAULT 0
);

Definirea interogărilor (queries)

Următorul pas, poate contraintuitiv, este să ne definim query-urile. Și facem asta într-un fișier denumit evident queries.sql. Vom defini câte o cerere pentru fiecare operație CRUD:

-- ~/Workspace/sqlcdemo/queries.sql

-- name: GetComment :one
SELECT * FROM comments
WHERE id = ? LIMIT 1;

-- name: ListComments :many
SELECT * FROM comments
ORDER BY bot_probability DESC;

-- name: SaveComment :execresult
INSERT INTO comments (
  email, comment_text
) VALUES (
  ?, ?
);

-- name: DeleteComment :execresult
DELETE FROM comments
WHERE id = ?;

-- name: PurgeBotComments :execresult
DELETE FROM comments
WHERE bot_probability > ?;

Veți observa adnotările cu numele de interogări și tipul de rezultat așteptat. Acestea ajută sqlc să genereze funcții și structuri sau obiecte specifice proiectului.

Generarea de cod

Odată ce avem cele trei fișiere: sqlc.yml, schema.sql și queries.sql putem rula comanda de generare de cod:

sqlc generate

Comanda sqlc generate va genera structuri pentru modele, funcții pentru cereri și interfețe:

În practică

Și acum e un simplu exercițiu de utilizare a acestui cod, în aplicația noastră pentru a insera un comentariu, îl listăm și apoi ștergem:

Pentru a face build-ul rulăm comanda de import a driverului de mysql și apoi build:

Pentru a ne conecta la o bază de date și a rula efectiv interogările de mysql voi folosi containerul mysql de docker cu următoarea configurație de docker-compose.yml :

# ~/Workspace/sqlcdemo/docker-compose.yml

services:

  db:
    image: mysql:lts
    restart: always
    ports:
      - "3306:3306"
    environment:
      MYSQL_ROOT_PASSWORD: secret
      MYSQL_DATABASE: sqlcdemo
      MYSQL_USER: sqlcdemo
      MYSQL_PASSWORD: secret

  adminer:
    image: adminer
    restart: always
    ports:
      - "8080:8080"

Și voi schimba username și parola în string-ul meu de conectare din fișierul main.go:

// main.go linia 18

db, err := sql.Open("mysql", "sqlcdemo:secret@tcp(localhost:3306)/sqlcdemo?parseTime=true")

Și rulez comanda de docker-compose și apoi build și run:

Pe github găsiți codul complet din acest exemplu. Acolo am adăugat și o cerere de marcare a unul comentariu ca bot comment și apoi am folosit integogarea PurgeBotComments pentru a-l șterge:

Dacă aveți o afinitate spre programarea funcțională, atunci cred că o să vă placă ideea de a împrumuta aspecte funcționale într-un limbaj orientat pe obiecte. În schimb, dacă nu aveți experiență cu limbajale funcționale (Haskell1, Scala2 sau erlang), e o ocazie să aflați despre aceste limbaje și să aplicați o paradimgă des folosită în acest domeniu: monad.

Ce este un monad (monadă)?

În termeni simpli, o monadă este un tipar de proiectare sau abstractizare, care ne permite să înlănțuim calcule și să gestionăm anumite aspecte ale acestora într-un mod structurat. Monada funcționează ca un "container" special care poate conține valori și de asemenea, să definească "efecte secundare" asociate cu aceste valori.

De se folosesc monadele?

Pentru gestionarea efectelor secundare: Monadele ne permit să tratăm efecte secundare precum date din surse externe (I/O), excepții și modificarea valorilor într-un mod pur funcțional3.

Structurarea codului: Monadele ajută să scriem cod mai clar și mai concis, facilitând înlănțuirea de operații și abstractizarea multor detalii de implementare.

Compunerea funcțiilor: Monadele permit compunerea de funcții care operează pe valorile închise în monade, creând astfel "pipeline-uri" de calcul.

Monada maybe

Aceasta reprezintă o valoare care poate fi, fie Just a (o valoare prezentă), fie Nothing (o valoare absentă). Se folosește pentru a modela valori opționale și pentru a evita erorile de tipul null pointer. Maybe ne permite înlănțuirea de operații, și implicit returnarea ”Nothning” sau o valoare implicite când operațiile nu sunt executate.

În pseudocod, putem defini monada Maybe astfel:

data Maybe val = Just val | Nothing

Implementarea Maybe în PHP

Această implementare ne ajută să evităm evaluările de genul

if (valoare) then:
  X
else:
  Y

tipice limbajelor de programărie imperative. Iar monada Maybe este relativ ușor de implementat.

Vom defini o clasă care suportă aceste 2 metode: just și nothing plus o metodă de map și una getOrElse pentru înlănțuire și respectiv un pas de obținere a valorii cu suport pentru valori default sau implicite:

Așa cum am menționat, avem cele două metode statice: Maybe::just și Maybe::nothing. just creează un obiect Maybe cu o valoare implicită, care poate fi null, iar nothing creează un obiect Maybe cu valoare NULL.

Metoda map() primește o funcție și o aplică valorii salvate pe obiectul Maybe. Dacă această valoare este NULL, va returna Maybe::nothing, adică un obiect Maybe fără valoare asociată. Iar dacă există o valoare pe obiect, valoare returnată de aplicarea funcției este returnată ca obiect Maybe prin Maybe::just.

Mai departe putem folosi această funcționalitate într-un controller de exemplu, care returnează JSON:

Acest controller, obține o valoare pentru email din $request și apelează un serviciu, UserService pentru a obține datele utilizatorului. UserService va returna un obiect Maybe, pe care apelăm map pentru a extrage un array cu datele relevante (name, email).

După map este înlănțuită metoda getOrElse, prin care obținem fie valoarea procesată la pasul anterior, fie valorile trimise ca implicite (‘name‘=> ‘Unknown‘, ‘email‘=>’Unavailable’) în cazul în care Maybe este nothing - adică userul nu este găsit.

Implementarea serviciului UserService:

Aici creăm obiectul Maybe care va transmite valoarea din repository, NULL sau un obiect User.

Dezavantajul obiectului Maybe

În implementarea de mai sus, deși am evitat evaluarea unei valori NULL în controller și funcția noastră primește garantat un obiect de tip User, tipul acestui argument este ascuns în valoarea obiectul Maybe. Așadar din acest punct de vedere am introdus un nivel de abstractizare care ascunde tipul argumentului.

De asemenea, restul aplicației noastre nu știe cum să intracționeze cu acest nou container de date, și pentru a rezolva asta ar fi nevoie să introducem Maybe sau Optional ca un tip de input / output pentru funcțiile care extrag date in altă sursă.În consecință asta ar putea complica implementarea cu un nou nivel de abstractizare.

Alte implementări notabile:

• github.com/php-slang/php-slang

• github.com/php-fp/php-fp-maybe

• github.com/chippyash/Monad

Dacă ați intrat odată google.com, atunci ați folosit un server proxy. Aproape toate serviciile oferite de companiile mari din tehnologie sunt conectate prin acest tip de servere, care elimină grija gestionării infrastructurii la nivel de rețea și datacenter. Două dintre cele mai interesante proiecte de software-defined networking sunt Pingora1 și Katran2. Primul este un set de librării sau mai bine spus framework, în Rust, destinat integrării de servicii de rețea cu un focus pe protocolul HTTP/S. Katran în schimb este o librărie în C++, destinată forwarding-ului și serverelor de load-balancing la nivelul de transport - TCP/UDP. Poate fi folosit ca un program în kernel (BPF3) și folosește XDP4 pentru performanță.

Tipuri de proxy servers

Sunt două tipuri de servere proxy, respectiv forward proxy și reverse proxy.

• Forward proxy: un server care rulează local sau pe rețeaua locală și prin care se face conexiunea către unele domenii, porturi sau protocoale. Poate fi folosit pentru a filtra traficul de pe internet, sau a genera rapoarte legate de trafic.

• Reverse proxy: un server care deservește un alt server, de exemplu un load balancer care servește trafic pe un singur domeniu dar în spate se conectează la alte servere prin rotație pentru a reduce încărcarea și a menține serviciile disponibile.

Un local (forward) proxy în limbajul C#

Pentru acest tutorial voi folosi editorul JetBrains Rider, dar puteți folosi orice editor. Desigur primul pas este să creez proiectul, pe care îl voi numi mscproxy:

Vom face un proxy pentru protocolul HTTP, așadar vom folosi un HttpListener(3). În Program.cs adăugăm următoarele linii:

Serverul nostru va asculta pe adresa locală (127.0.0.1) pe portul 7777. Este important ca portul ales să fie mai mare de 1024 pentrua evita zona privilegiată și conflicte cu alte servicii. Putem compila acest program (desigur nu uitați să adăugați acoladele care lispesc din screenshot) și mesajul se va afișa în consolă:

Listening on port 7777 ...

Procesarea request-ului

Serverul nostru va primi o cerere de la un client (browser) pe care mai apoi o va procesa și va returna răspunsul, o pagină web sau un mesaj de eroare. Vom avea nevoie să procesăm mai multe cereri în paralel, de aceea apelăm la fire de execuție (threads):

Clasa ProxyThreadRelay implementează procesarea request-ului în contextul pasat de la listener și va fi rulată într-un fir de execuție separat de programul (serverul) nostru care ascultă pentru cereri noi. Aceasta este resposabilă de transmiterea request-ului către server și are două metode processRequest() și asyncResponseCallBack():

Salvăm contextul ca proprietate, iar în processRequest contruim un HttpWebRequest din url-ul specific contextului. Re-setăm niște parametrii (keepAlive și UserAgent) și la final lansăm cererea cu pasarea metodei care va procesa răspunsul.

asyncResponseCallBack, după cum îi spune și prefixul este o metodă asincronă, care va fi chemată atunci când vine un răspuns de la serverul care primește cererea înaintată de proxy:

Aici citim răspunsul, îl transformăm într-un byte array și îl copiem în responseStream care va fi trimis către clientul serverului nostru proxy. Aici am pus și un comentariu, unde putem modifica răspunsul în cazul în care acesta este text/html.

RequestState

Această clasă este un container pentru webRequest și context, și ne ajută să pasăm un obiect unic între cele două metode de mai sus de la processRequest la asyncResponseCallBack:

Conectarea cu proxy

Prima mențiune ar fi că proxy-ul nostru este doat HTTP, așadar nu ne vom putea conecta la servere care forțează conexiuni prin HTTPS. Vom porni aplicația și serverul nostru, care va asculta pe portul 7777, apoi folosim utilitarul Invoke-WebRequest din Powershell pentru a ne conecta prin proxy la www.example.com:

Iar în consola IDE-ului vor apărea mesajele de log:

Știm cu toții de la cursul de baze de date și MySQL că orice rând ar trebui să fie identificat printr-un număr unic, respectiv un ID, care dacă este și index primar face accesarea acelui rând super rapidă. Dacă ați chiulit de la curs¸ nu-i bai, dar vă atenționez că acest articol este mai tehnic!

Ce-i un UUID?

Așadar, pe o bază de date relațională avem identificatori ca și chei primare pentru a accesa acele valori fără a penaliza performanța liniar cu adăugarea de rânduri noi. Care altfel, ar fi cel mai nefast scenariu pentru o bază de date!

Indecșii clasici, sunt de obicei numere pozitive (unsigned int sau bigint), tipuri destul de mari pentru a permite valori de ordinul miliardelor, și deci a susține un număr foarte mare de înregistrări. Însă aceste valori se repetă de la tabel la tabel, avem indecșii 49, 50 și 51 pe tabela users și 49, 50 și 51 și pe tabela admin_users. ID-ul 21 poate aparține la doi utilizatri, unul fiind admin.

Apoi, acești indecși sunt secvențiali: 1, 2, 4, 6, 7, 9; și nu se pot genera valori dacă sistemele nu sunt conectate cu baza de date pentru a accesa secvența precedentă, deci nu oferă toleranță la partiționare. Așa s-a născut conceptul de UUID - Universally Unique ID.

Aceste valori sunt stocate în binar sau ca șiruri de caractere, și sunt generate cu scopul de a identifica o întregistrare unică pe unul sau mai multe seturi de date.

Scenarii în care apelăm la UUID-uri

De cele mai multe ori uuid-urile sunt folosite pentru a oferi referințe între sisteme care fie sunt decuplate sau ne dorim să poată funcționa independent unul de altul.

Un frontend poate genera UUID-uri

Cel mai mare avantaj al UUID-urilor este că pot genera unul fără a cunoaște secvența precedentă, stocată pe tabela de date. În cazul MySQL de exemplu funcția mysql_insert_id este folosită pentru a determina ultima valoare secvențială, înainte de a insera un rând nou, dar pentru asta e nevoie să fim conectați la serverul MySQL. Spre deosebire, un UUID, poate fi generat din cod, chiar dacă aplicația nu este conectată la server. Și de exemplu pot genera și afișa un URL pentru o imagine care urmează să fie prelucrată de server, înainte ca imaginea să fie efectiv încărcată.

Collecții de date fault-tolerant

Un alt scenariu este acela în care am mai multe aplicații, și toate vor stoca date într-o colecție distribuită pe mai multe mașini sau noduri, pentru a prioritiza salvarea datelor, indiferent dacă unul sau mai multe noduri sunt offline.

Prevenirea de race-conditions și partiționare

Uneori avem nevoie de să putem stoca date într-un ritm susținut și cu latențe foarte mici. De exemplu mesajele de log generate de o aplicație sau tranzacții monetare care este imperativ să fie stocate chiar dacă înregistrarea este duplicată sau incompletă.

Standardul oficial UUID și copii lui

RFC 95621 este specificația de facto pentru sistemele și librăriile care generează identificatori globali unici. Sunt mai multe versiuni în această specificație. Din păcate unele versiuni nu sunt compatibile între ele. Iar versiunea 2 este de evitat. Cea mai populară și mai stabilă versiune este UUIDv4, și este cea recomandată la vremea acestui articol.

Dincolo de standard

Pe lângă RFC, sunt și alte specificații pentru UUID-uri. Desigur scopul unui generator este de a reduce coliziunile, dar în funcție de nevoile aplicației se poate folosi un generator care admite o rată de coliziuni, oferind în schimb viteză, suport pentru odronare sau variante mai scurte și mai rapid de transmis.

ULID2: este o alternativă care generează uuid-uri care sunt url-safe, fără caractere speciale și sortabile. Singura limitare este că se pot genera maxim 2⁸⁰ versiuni pe millisecondă.

NanoID3: ca și ulid, generează șiruri url-safe, oferind viteză sporită de generare. Permite configurarea lungimii, cu riscul de a avea o șansă mai mare de coliziuni, însă șirurile generate nu oferă suport pentru ordonare.

TypeID4: îmbină sportul pentru ordonare cu un prefix, care indică tipul sau entitatea referențiată.

Alte versiuni notabile: CUID, Snowflake ID, sqids.

UUID ca și cheie primară

Răspunsul scurt este NU, adică evitați folosirea de UUID-uri ca și chei primare. Deși tentația e mare și cu siguranță veți găsi pe web surse care declără că versiunea lor este bună pentru chei primare. Dar pe măsură de setul de date crește, accesul și inserția va fi îngreunată deoarece baza de date nu poate indexa și balansa eficient în lipsa unor chei implicit sortabile. Totuși țin să mențiionez că asta este specific bazelor de date relaționale (*SQL) care aplică indexare prin algoritmi binary tree sau B-Tree. În cazul bazelor de date NoSQL, indexarea se face prin algoritmi de hashing și aici cheile primare sunt UUID-uri.

Așadar, răspunsul mai lung este în funcție de sistemul de baze de date folosit de aplicație, dar puteți oricând folosi UUID-uri ca și chei secundare.

Odată cu versiunea 8.1, PHP a introdus fibers1. Dar fibers, nu trebuie confundat cu fire de execuție, respectiv threads. Așadar pentru a elimina confuzia, și a ne face o imagine despre conceptul de asynchronous code, o să vă arăt în aceste rânduri câteva exemple practice:

Ce sunt fibers?

În PHP, fibers sunt o strategie de a grăbi execuția unor task-uri, iar fibrele se pot executa și în paralel - de unde și confuzia cu fire de execuție. Însă, spre deosebire de threads, fibers nu execută cod PHP în paralel - PHP este single-threaded. Dar ne permit să ”împachetăm” un task extern, care poate fi executat în paralel.

Fibers sunt eficace doar dacă se îndeplinesc următoarele condiții:

• Interacționezi cu resurse externe aplicației, al căror status poate fi procesat în paralel cu rularea aplicației. De exemplu un sub-proces sau sub-shell sau o cerere în rețea.

• Poți cere sau interacționa cu resursa, fără să blochezi execuția codului. De exemplu o cerere către baza de date, de a cărui rezultat depinde o condiție ulterioară, nu poate fi executată în paralel - codul așteaptă rezultatul să continue.

Exemplu practic: generarea de video din imagini cu ffmpeg

Pentru o demonstrație, ne propunem să generăm câte un clip video (un reel) pentru imaginile de cu extensia jpg, salvate în trei directoare, folosind utilitarul ffmpeg2.

Imaginile mele sunt plasate, în directoarele clip1, clip2, și clip3 sub directorul assets al proiectlui:

Pentru a converti fiecare dintre aceste colecții de imagini într-un video, unul după altul sincron, aș putea folosi următorul cod:

Pe laptopul meu se execută destul de rapid, respectiv în 2.9 secunde:

4 folders processed in 2.9 seconds

Un exec care nu blochează

exec-ul folosit mai sus, este o operațiune care blochează - se convertește fiecare foder unul după altul. În ordinea definită. Pentru generarea clipului 4 (clip4.mp4), așteptăm prelucrarea tuturor celor 3 foldere precedente. Pentru a folosi fibers, mai întâi este necesar să convertim aceste exec-uri la o variantă care nu blochează și să o exportăm într-o funcție.

Avem nevoie de proc_open3: acesta nu blochează execuția scriptului până la finalizarea comenzii ffmpeg, ci lansează un shell pe lângă script-ul de php la care ne putem conecta, la nevoie pentru a verifica statusul comenzii:

Veți observa că din perspectiva iterației, acest cod este tot unul blocant, deoarece am introdus un while și un usleep. Dar am introdus intenționat aici bucata de cod blocantă, care o vom elimina prin introducerea fibers.

Să ”depănăm” cu fibre

Acum că avem o funcție care nu blochează, puteam crea câte un fiber pentru fiecare director din care dorim să generăm clip:

Dacă am pus fiecare generare într-o fibră se vor executa în paralel și mult mai rapid, nu? Ei nu încă, pentru că nu am eliminat partea blocantă din funcția noastră createFolderClip și fibrele vor rula codul asincron doar cu Fiber::suspend().

PHP Asincron

În locul lui usleep introducem suspend. Și pentru a putea obține statusul fără să așteptăm în foreach-ul care lansează fibrele, le adăugăm într-o listă și le rezumăm într-o buclă:

4 folders processed in 0.7 seconds

Acum pot converti cele 4 foldere în mai puțin de o secundă!

Paralelism, dar cu măsură

Codul de mai sus a convertit doar 4 directoare. Toate au rulat în paralel, fiecare pe câte unul din ce 12 procesoare de care dispune mașina mea. Însă dacă am generaliza codul să ruleze pe un număr variabil de directoare, va fi necesar să limităm numărul de fibre care sunt rulate în același timp, pentru a evita context switching4. În exemplul de mai sus am putea implementa asta accesând $fiber→resume() doar pentru 12 fibre odată, și pe măsură ce acetea returnează, să rezumăm următoarele.

Puteți găsi codul din exemple pe github: https://github.com/moustacios/php8-tutorials/tree/main/php8-fibers

Cred că una dintre cele mai dificile momente la începutul unui sprint, sau al unui deliverable este acela al estimărilor. Am lucrat atât în proiecte care adoptau procese ”agile” cât și în echipe cu waterfall sau pe cont propriu ca freelancer, unde nu prea ai ce tehnică să adopți. Dar în majoritatea cazurilor, cu câteva excepții notabile - când am fost implicat în echipe de produs, am fost în situația de a da estimări.

Eu mă poziționez împotriva estimărilor: cum să știi cât o să dureze ceva ce nu ai făcut niciodată? Acel modul sau feature va fi creat, fie cu ajutorul unor librării sau alte module, însă dacă ți-e dat să-l faci, e pentru că nu există ceva identic. În concluzie orice estimare de timp va fi o încercare de a prevedea viitorul - un exercițiu riscant ținând cont de faptul că de previziune depinde bugetul. Plus că sunt atâtea variabile: poate ești nevoit să îți iei concediu, sau poate îți dai seama că ai nevoie de mult mai mult timp, dar asta după ce ai început implementarea, și s-a scurs deja jumătate din timpul alocat.

#Deadlines

O altă problemă, mai ales pentru echipele agile, este că estimările se transformă în deadlines. Nu de puține ori mi s-a întâmplat să dau o estimare și apoi data respectivă să apară într-un comunicat de presă, sau toată compania să afle că din data X vor avea gata respectivul modul, sau să se felicite pentru această reușită. În aceste cazuri, mai ales pentru juniori este foarte greu să dea estimări - deoarece au puțină experiență pe proiect nu vor reuși să livreze în același timp ca un senior, și de multe ori vor fi puși în situația de a da estimări mai mici, pentru că un coleg senior este de altă părere. Sau juniorii vor primi întodeauna task-uri ușoare, pentru a se înscrie în sprint, ratând astfel oportunitatea de a învăța și a deveni mai experimentați pe proiect.

Desigur, pe termen lung, echipa va deveni mai rigidă, mai puțin dispusă să-și asume riscuri și condusă mai degrabă de aceste deadline-uri. Pentru că cine se înscrie în estimare, este văzut ca un performer în ochii managerilor.

#NoEstimates

Allen Holub1 susținea această cauză - dacă estimările nu se respectă, ce rost mai are să le dăm? Agile, nu este un proces dependent de timp, și de mult ori estimările au de fapt rolul de a stabili direct costurile clientului, ceea ce îi face pe manageri să fie obsedați de durată mai degrabă decât de rezultat. Iar aici este un conflict: devreme ce managerul dorește să știe cât îl costă un modul, pe mine ca inginer mă pasionează să livrez în producție acel modul - adică rezultatul este acel moment în viitor când am trecut de toate fazele pentru livrare în mediul de producție: arhitectură, inventariere cerințe și dependințe, evaluarea implementării inițiale, testarea și demonstrație. Fiecare dintre acești pași va necesita o bucată de timp, și de cele mai multe ori depind de alți colegi să poată fi duse la bun sfârșit. Mă pregătesc pentru acel moment din viitor, când voi putea livra modulul, însă când va fi acel moment este foarte greu de stabilit. E similar cu a cere unei persoane care tocmai a început cursurile de înot, cât timp îi ia până să înoate în mare.

Se poate agile fără estimări!? Da se poate, și o să revin asupra subiectului într-un articol viitor. Însă acum o să dezbat problema estimărilor, atunci când sunt necesare:

#Bugete - dar de timp

Din păcate, în multe situații nu putem aplica sfatul lui Allen Holub, și să renunțăm la estimări. De exemplu, dacă ești freelancer clientul îți va cere un buget, și vei fi nevoit să îți faci un calcul de timp. La fel și la modelul Time and Material, practicat în companiile de outsourcing. Clientul se așteaptă să știe, orientativ, cât va costa implementarea.

Dar, în același timp dorim să reducem presiunea și pericolul ca estimările să se transforme în deadlines, mai ales pentru juniori sau teams leads care vor fi puși în situația de a-i ajuta pe colegi în cazul în care au dificultâți de a se încadra în sprint.

O metodă pe care am aplicat-o cu succes, este aceea de a crea bugete de timp, adică îți rezervi un număr de ore/zile pentru un anumit task. Dar nu numai că indici acest lucru în sistemul de tracking cu story points de exemplu, ci și pontezi sau pui acel timp în avans pentru acel task. Această simplă operație, mă face să mă concentrez mai ușor, pentru că nu mai am grija duratei - timpul e deja alocat.

Apoi dacă azi am bugetat timp pentru un modul din acest sprint, atunci orice alte întâlniri sau task-uri la care le voi acorda timp în sprint, le voi ponta separat și îmi voi da seama imediat dacă aceste extra task-uri depășesc capacitatea rezervată de mine sau nu. Îmi va fi mai ușor să comunic timpul pe care îl pot aloca meeting-urilor sau suportului pentru colegi. Și aceste interacțiuni sunt foarte importante, pentru a fi eficace fiecare coleg din echipă va avea nevoie de timp rezervat pentru ele.

Desigur, dacă a luat mai puțin, la sfârșit poți corecta pontajul să reflecte timpul efectiv, dar aceste corecturi se fac oricum la estimări.

O altă mențiune importantă, pentru bugetele de timp, este să nu rezervi timp pentru task-uri pe care nu le iei tu, deci fiecare coleg decide de cât timp are nevoie. Și se evită bugetarea de timp pentru task-uri care nu sunt începute în sprint. Pe principiul dacă nu este important atunci nu se estimează.

Eu folosesc de aproape un an tehnica bugetelor de timp. De multe ori este combinată cu story points și se complementează chiar bine, deoarece evităm confuzia dintre dificulate și durată. Sper că îi ajută și pe cei care fac freelancing, pentru că poate fi dificil să jonglezi cu mai mulți clienți, unde estimările influențează în mod direct bugetele clienților.

(c) Photo by Jason Goodman on Unsplash

Am și eu la ”wishlist” vreo 15 modele de laptop-uri. Cu prețuri de la 3000 la 7000 de lei. Sunt foarte multe modele cu specificații extrem de variate, și stau și mă întreb cum, un laptop cu 16 GB de RAM poate să coste la fel cu unul cu 40 de GB de RAM? O fi având procesor mai puternic, sau durează bateria mai mult, sau are placă video dedicată… .

Și uite așa, mă hlizesc la toate modelele și combinațiile posibile cu foarte mare ezitare, pentru că mi-e foarte greu să mă decid: iau unul cu mai mulți RAM dar fără placă video dedicată? sau unul cu placă și mai multe nuclee la procesor?

Ideea e că, dacă de exemplu, începi de la o specificație cum am căutat eu cu minim 32 GB de RAM, o să vezi că acei rami pot să valoreze de la 3500 de lei în sus, iar limita e undeva pe la 7000 de lei. Respectiv o să găsești laptopuri cu 32 de GB la dublu preț și desigur atunci de ce să nu-l iei pe cel mai ieftin?! Să vă dau și un exemplu:

https://www.emag.ro/compare/DNQV1DYBM,DZPH5DYBM,D1400MYBM,DX8TN2YBM/

Aceste modele au toate câte 32 GB de RAM, procesor cu 8 nuclee (cu o singură excepție) și placă video dedicată cu 6GB de VRAM. Iar cel care are 12 nuclee la procesor, nu este cel mai scump. De obicei aș zice că dacă laptop-ul e de ”gaming” șansa este să plătești mai mult doar pentru câteva gimmick-uri care nu influențează performanța.

Ei și uite așa, în loc să tot stau să compar și să mă gândesc, mi-am făcut o formulă. Pornind de la ideea că ai lua toate specificațiile astea: număr de nuclee, capacitate SSD, capacitate RAM, VRAM și durata bateriei și le-ai contopi într-un coeficient pentru fiecare laptop ai putea să calculezi cât plătești pentru fiecare ”upgrade” sau punct de performanță în plus. Formula face abstracție de câteva elemente cum ar fi frecvența procesorului, pornind de la premiza că majoritatea au procesoare peste 3 GHz, sau de frecvența memoriei RAM. Iar stocarea - întodeauna alegeți SSD.

De exemplu eu am comparat câteva modele cu o capacitate sensibilă de memorie RAM, respecviv 48 sau 64 de GB, cu sau fără placă video dedicată. Și aici poate o să ridicați sprâncenele - păi cum un laptop cu placă video separat și mai multe core-uri, are mai puține ”puncte” decât unul fără?! Deoarce Dell-ul are o baterie care ține 6 ore față de acel Lenovo cu RTX. Iar diferența este sensibilă - de 3000 de RON între cele două, doar pentru placa video și câteva core-uri în plus. Cu alte cuvinte pentru placa video extra, rămânem cu două ore de baterie. Mai bine iau un desktop PC care vine cu 12 GB VRAM. Uite aici exemplul ca să nu ziceți că bat câmpii:

Am pornit de la ideea că RAMii sunt cel mai important factor, deoarece versatilitatea unui laptop depinde de câte aplicații poate pune în background sau în sleep și sistemele de operare mai noi sunt optimizate pentru asta. Apoi capacitatea SSD-ului al doilea factor, pentru că ultimul lucru care ți l-ai dori eeste să rămâi fără spațiu pe disc când lucrezi la un proiect. Proiectele pe care lucrez eu au atașate în mod normal câțiva GB de assets.

Numărul de nuclee plus durata de viață a baterie, sunt secundare, de obicei se influențează în mod direct - multe core-uri consumă mai multă baterie iar la un laptop vom avea și thermal throttle. Deci cu ce te ajută mai multe core-uri dacă le poți folosi doar când ai o priză aproape!

Iar VRAM-ul, deși balansează în jos e cel mai puțin semnificativ. V-am arăttat și în exemplul de mai sus - pe un laptop, doar o placă video ajunge să te coste cât un desktop PC întreg. Da dacă ai niște specificații foarte clare, gen, ai nevoie de CUDA cores sau dezvolți jocuri unde ai nevoie specific de ray-tracing, atunci poate merită investiția.

Desigur veți observa rezultate mai apropiate și mai relevante, când comparați laptop-uri cu configurații similare. De exemplu dacă folosiți suita Adobe pentru editare foto/video, veți avea nevoie de o placă video dedicată cu minim 4 GB VRAM. Pentru Macbook-uri nu pot recomanda formula asta, deoarece acestea sunt o altă ligă. Ideea e să afli care e cel mai ieftin produs comparat cu performanțele pe care le oferă, și când ai un buget stabilit zic că este foarte utilă.

Puteți compara și voi folosind acest spreadsheet: https://docs.google.com/spreadsheets/d/1r1iqKo7aVsFkbnt0f9c6vLcCOa0jpT0IhjuCLz8765w .

Fie descărcați și editați sau faceți o copie. Sper să fie de folos.

Când vorbim de versionare pentru cod și software în general, utilitarul de facto în 2024 este încă git. Dar nu a fost întodeauna așa. Cei care își amintesc înainte ca acesta să devină stabil și popular foloseam svn, mercurial sau cvs. Eu îmi amintesc cu nostalgie de vremea când foloseam Tortoise SVN1.

În acest articol o să vă spun și despre alternative la Git ca sistem de versionare, dar și despre câteva unelte care vă pot ușura interacțiunea cu git din linia de comandă:

Gitu

Încă de la versiunea 2, interfața cli cu care vine git este destul de bună, dar nu chiar intuitivă. Iar pentru unele acțiuni rulezi aceleași comenzi repetitiv. Apoi pentru cazurile în care faci un log sau diff este extrem de utilă o interfață grafică.

Gitu este un utilitar din linia de comandă, inspirat de Magit - extensia pentru Emacs, care îți permite să execuți o serie de comenzi folosind macros - combinații de taste. Acesta nu înlocuiește git, dar te ajută să sari peste comenzi repetitive, să vizualizezi istoricul și diff-urile cu o interfață și oferă sugestii pentru acțiuni în funcție de context.

Din păcare suportul pentru WSL2 are câteva bug-uri și nu am reușit să îl instalez cu cargo, dar îl recomand pentru simplitate și portabilitate.

Sapling

Una dintre criticile menționate des la adresa git, este că e dificil de scalat - la miloane de fișiere și mii de dezvoltatori. Google de exemplu, în mod faimos, folosește un sistem intern de versionare menținat pe forumuri ca Piper, care din păcate nu este open source. Cel puțin Meta au decis să publice codul sistemului lor de versionare - Sapling. Codul pentru componenta de client, este disponibil pe Github sub GPL.

Sunte multe de spus despre acest SCM, dar pentru a ține acest articol în limitele unei email voi nota următoarele:

Acesta diferă fundamental de git, ca mod de operare, dar totodată oferă interoperabilitate cu git și GitHub. Îți dă posibilitatea să trimiți un pull request direct din cli, și să vizualizezi un log detaliat per branch. Tototadă acesta descurajează branch-uri cu denumiri sugestive și încurajează folosirea PR-urilor în loc, ca feature branches. Saplin nu are un staging area. Poți face un commit ca și cu git, iar acesta se va aplica la toate fișierele urmărite. Poți ascunde sau ”undo” commit-uri publice cu un nou commit și vine cu o interfață web care oferă un istoric interactiv (smartlog).

Smartlog, oferă o serie de avantaje peste git log, pe lângă componenta vizuală, îți oferă posibilitatea de a muta commit-uri (rebase) sau da checkout (goto) pe alt branch.

Din păcare serverul sapling nu este open source, în consecință singura modalitate de a-l adopta este folosind interoperabilitatea cu github.

Jujutsu

JJ este un sistem dezvoltat recent, în limbajul Rust, a cărui misiune principală este să decupleze layer-ul de stocare de cel de control al versiunilor. În acest fel, fiind mult mai ușor de scalat.

O altă şchimbare notabilă față de git, este că jj consideră copia în lucru (working-copy) ca fiind un commit, eliminând astfel erorile tipice operațiilor de checkout sau pull din git atunci când avem modificări pe working-copy. Practic toate operațiile în jj, au afect asupra unui commit. Poate părea contraintuitiv, însă rezultatul este că poți face mai multe versiuni locale pe branch-uri diferite de exemplu și să le testez fără a fi blocat de nevoia de a crea efectiv un commit. Git în acest scenariu te va alerta: ”atenție să nu pierzi vreun fișier” - e nevoie să faci un commit înainte de checkout. Pe când JJ te lasă să schimbi branch-ul, eventual poți adăuga noi modificări iar când ești gata ”salvezi” acel commit sau îl adaugi la cel precedent cu squash.

Mai sunt câteva diferențe legate de ramuri (branches), și de conflicte, dar dacă vi se pare interesant vă recomand să citiți mai multe pe pagina proiectului. Partea cea mai bună este că suportă repository-uri .git și deci poate fi folosit în paralel cu sistemul de versionare.

Mențiuni notabile:

• www.fossil-scm.org

• www.stacking.dev

• en.wikipedia.org/wiki/GNU_Bazaar

• www.pijul.org

• www.git-cliff.org

• github.com/dlvhdr/gh-dash

Referințe:

• github.com/altsem/gitu

• engineering.fb.com/2022/11/15/open-source/sapling-source-control-scalable

• sapling-scm.com

• github.com/martinvonz/jj

Printre capacitățile modelelor de limbaj mai noi cum sunt llama2, sau mistral-7b se numără și acela de a raționa într-o manieră similară creierului uman. Astfel pot oferi răspunsuri la probleme de matematică de exemplu:

Gemini, generează răspunsul însoțit de o explicație detaliată a pașilor. Însă, nu putem folosi acest răspuns pentru a fi citit de un alt program de exemplu, care ar fi responsabil de generarea unor rapoarte sau statistici, și tot ce are nevoie programul este numărul rezultat:

Chiar și dacă primește intrucțiunea, Gemini menționează ”voturi” la sfârșit.

Extragerea informației relevante

Aceasta este una dintre aplicabilitățile pe care le are Guidance - să capteze doar partea relevantă a răspunsului unui LLM:

Întrebare: Dintr-o populație de 236754 de persoane, 14872 au răspuns la sondaj. Ce procentaj din populație a răspuns la sondaj?

Răspuns (%): 6

Titlu generat: "Reanimat și Rezervat: O Viață de Zombie într-o Pensiune"

Next level - generare de JSON

Folosind acest tool, putem ”programa” un LLM să genereze un răspuns în formatul JSON. Pentru a face asta e nevoie să ajustăm codul, ca să includă câteva indicii despre format:

The following is a list of 10 big cities, starting with London in JSON format. The keys would be names of the cities and value should be their population size in millions:

{
    "London": 8.9,
    "New York": 8,
    "Tokyo": 13,
    "Mumbai": 20,
    "Delhi": 16,
    "Shanghai": 24,
    "SaoPaulo": 21,
    "MexicoCity": 21,
    "Osaka": 19,
    "Cairo": 20,
}

Mai departe putem integra acest generator într-o funcție, pentru a crea un număr arbitrar de valori:

The following is a list of 6 big cities, starting with London in JSON format. The keys would be names of the cities and value should be their population size in millions:

{
    "London": 9,
    "NewYork": 8,
    "Tokyo": 13,
    "Mumbai": 20,
    "SaoPaulo": 21,
    "Delhi": 17,
}

Această abordare poate fi extinsă, pentru a permite modelului de limbaj să folosească API-uri de unde să culeagă date și să răspundă la promt-uri în limbaj natural.

De asemenea Guidance AI poate fi folosit pentru a reduce din costurile de utilizare a unor modele a căror cost depinde de numărul de token-uri folosite pentru generearea unui răspuns. Sau pentru a reduce ”zgomotul” generat de o rețea neuronală cu scopul de a-l transmite unei alte rețele ca sursă.

Referințe:

• https://github.com/guidance-ai/guidance

• (EN) https://lightning.ai/lightning-ai/studios/structured-llm-output-and-function-calling-with-guidance

Proiectul Node Package Manager este, pe lângă utilitarul care descarcă și rezolvă calea către pachetele unui proiect Javascript, și registrul care găzduiește aceste pachete. Și deși avem câteva alternative viabile la npm ca și dependency manager, cum ar fi yarn1, pnmp, deno sau bun2, la capitolul registru de pachete NPM nu are competitor. Desigur, faptul că npm vine ca în bundle-ul de instalare nodejs, și devreme ce npm folosește npmjs implicit ca și registru, această strânsă legătură între cele două proiecte le-a făcut aproape inseparabile. Din păcate din lipsa competiției, ducem lipsa și de inovație pe acest front - ultimul update seminificativ pe care l-a primit a fost suportul pentru provenineță de acum 7 luni3.

Din fericire asta e pe cale să se schimbe, și, cel puțin până acum avem anunțați doi competitori la registrul de pachete:

JSR

Creat de echipa din spatele proiectului Deno și totodată de Ryan Dahl, creatorul nodejs, acest ecosistem (package manager și registry), își propune să rezolve multe dintre dificultățile de a publica pachete Typescript cu npm. Așadar oferă suport nativ pentru acest limbaj: va genera automat documentații și definițiile de tipuri - fișierele d.ts și desigur pote fi folosit cu pachete în Javascript în locul NPM.

Din păcate pentru unii dar din fericire pentru alții care nu depind de librării cu CommonJS sau versiuni vechi de Node, JSR va suporta doar module standard EcmaScript (ESM), care sunt deja standard4.

O altă notă importantă este generarea definițiilor pentru tipuri, care este un proces ce consumă resurse. JSR va genera definiții doar pentru acele tipuri definite explicit. ”Slow types” vor fi înlocuite cu any iar documentația generată s-ar putea să le omită5.

VLT (Volt)

Despre acest proiect avem mai puține detalii, dar unul important de menționat este că a fost anunțat de către creatorul NPM - Isaac Z. Schlueter6. Iar unul dintre articolele pe care le-am găsit pe blogul proiectului descrie bug-ul numit manifest confusion, pe care dacă ești pasionat sau responsabil de securitate ți-l recomand: The massive bug at the heart of the npm ecosystem.

Așadar se pare că acest proiect va pune un accent mai mare pe securitatea pachetelor și ecosistemului ceea ce este un lucru bun.

Noua comandă sudo este disponibilă începând cu Windows 11 build 26045 sau mai recent, fiind necesară activarea ei din meniul de Settings > Developer Features.

Aceasta nu este un port al comenzii omonime din linux, și nici o versiune emulată, deoarece modul de funcționare a permisiunilor între cele două sisteme este fundamental diferit. Așadar sunt două utilitare cu opțiuni diferite. De asemenea, noul sudo nu este un înlocuitor pentru runas, care permite rularea sub orice user, inclusiv unul cu drepturi de administrare. Utilitatul sudo este limitat la comanda/procesul pe care îl primește ca argument și rulează doar cu drepturi de administrator.

Sintaxa, este asemnănătoare cu cea din linux sudo [comandă]:

sudo netstat -ab

Putem configurara cum va rula sudo o comandă:

• Într-o fereastră nouă (forceNewWindow): va rula aplicația într-o fereastră de terminal nouă, imitând comportamentul comenzii runas /user:admin

• Input closed (disableInput): va rula comanda cu permisiuni elevate în terminal, dar fără input. Altfel spus procesul lansat cu sudo nu are access la input-ul din terminal și nu vei putea interacționa cu el. Acest mod oferă posibilitatea de a mitiga unele riscuri de securitate2.

• Inline (normal): similar cu comportamentul sudo de pe alte platforme, va rula comanda cu permisiuni elevate, oferind totodată access la stdin/stdout din terminal.

Aceste moduri pot fi rotite cu opțiunea configEnable:

sudo config --enable <forceNewWindow|disableInput|normal>

Gsudo

Gsudo este un proiect open-source similar, care emullează sudo pentru Windows. Poate fi instalat cu scoop sau winget și dispune de mai multe opțiuni decât varianta oficială: gerardog/gsudo. Așadar dacă doriți opțiuni de selecție a unui utilizator, Local System accounts sau montarea de network drives folosiți gsudo.

Nu am foarte multă experiență cu Python, însă cred că pot recunoaște un framework web cu potențial atunci când îl văd. Mountaineer, păstrează structura MVC cu care ne-am obișnuit, însă a renunțat complet la tempate-uri generate în backend și deleagă această ”corvoadă” către un alt framework deja matur - React; Care pe lângă client-side rendering, este configurat implicit să facă server-side rendering la html.

Așadar, acest framework este o alipire între FastAPI și ReactJS, dar nu doar atât, deoarece că vine cu tooling și suport pentru data binding bidirecțional din modele către frontend-ul de React.

Structura unui proiect

.
├── README.md
├── docker-compose.yml
├── poetry.lock
├── pyproject.toml
└── webapp
    ├── __init__.py
    ├── app.py
    ├── cli.py
    ├── config.py
    ├── controllers
    │   ├── __init__.py
    │   ├── detail.py
    │   └── home.py
    ├── main.py
    ├── models
    │   ├── __init__.py
    │   └── detail.py
    └── views
        ├── app
        │   ├── detail
        │   │   └── page.tsx
        │   ├── home
        │   │   └── page.tsx
        │   └── main.css
        ├── package.json
        ├── postcss.config.js
        └── tailwind.config.js

Top-level, avem fișierul de configrare, un lockfile pentru Poetry1 specific proiectului și un docker-compose, unde definim servicii externe. Implicit tool-ul de generare de cod, folosește PostgreSQL ca bază de date.

Apoi, sursele aplicației, sunt organizate în cele trei categorii: models, controllers și views. Tot ce ține de React este în localizat în views, unde avem un package.json și fișierul de configurare Tailwind2. Aici avem nevoie de node/npm pentru instalearea pachetelor specifice.

SSR cu React și useServer

Pentru data binding și server side rendering, mountaineer folosește un hook special: useServer, care oferă componentelor UI datele definite în modele și leagă acțiunile în backend:

Acestea vor fi autocompletate de către IDE, iar state-ul este întodeauna sincronizat, folosind un decorator special și anume @sideeffect, în controller:

Mountaineer detectează prezența funcției cu efect secundar și evaluează semnătura acesteia. Apoi o expune către frontend ca o funcție asincronă.

HomeController, expune funcția add_todo iar la adăugarea unui item, componenta își va reîncărca lista, fără a fi nevoie de extra cod.

Această caracteristică se extinde cu suportul pentru SSR - state-ul rămâne pe server și aplicația poate fi utilizată și când javascript este dezactivat.

SQLModel + Pydantic

Modelele se definesc în directorul models, și fiecare model este și un obiect Pyhton. Pydantic asigură validarea și suportul pentru adnotări în IDE:

Această convenție păstrează compatibilitatea cu SQLAlchemy, facilitând migrarea de între cele două ORM-uri dar și integrarea cu FastAPI.

Framework-ul este la versiunea 0.4, așadar nu este încă recomandat pentru proiecte deja în producție, însă pentru un hobby project sau un MVP mi se pare potrivit.

Puteți afla mai multe despre Mountaineer pe pagina proiectului: www.mountaineer.sh sau pe github: piercefreeman/mountaineer.

Încă de la versiune 5.4, PHP dispune de un web server pentru depanarea și rularea scripturilor sub PHP SAPI. Îl poți folosi ca să testezi rapid rularea unui script din borwser sau la o cerere Ajax:

Dar pe lângă asta, mai putem configura un director, din care să fie ales un index.php sau index.html, cu fișiere statice și non-statice, sau chiar să rutăm cererile în funcție de cale. Sintaxa pentru acest utilizar este următoarea:

php -S [domeniu|ip]:[port] [-t dosar] [script]

De exemplu, pentru a servi un director, folosim opțiunea -t urmată de calea acestuia:

Toate fișierele din server/public vor fi servite direct (imagini sau html), iar fișierele cu extensia .php vor fi executate.

Rutarea cererilor

Putem crea un ruter pentru a simula o aplicație care direcționează cererile către alte funcții sau fișiere, în funcție de cale:

Iar începând cu versiunea 7.4, putem configura un număr de instanțe (workers) care să fie lansate individual folosind variabila PHP_CLI_SERVER_WORKERS. Astfel putem testa cu cereri concurente către același script. În cazul în care avem un singur worker, cererile vor aștepta una după cealaltă. Așadar e bine să configurăm cel puțin 2 workeri dacă pe lângă scriptul de php mai servim și alte resurse în pagină cum ar fi fișiere css, javascript sau imagini:

Referințe

• [EN] Built-in web server

• [EN] Run a PHP Web Server to Quickly Serve Local Files

Dacă sunteți dezvoltatori web, ați folosit cu siguranță consola din Chrome sau din alte navigatoare pentru a depana codul Javascript sau integrări cu serviciile terțe. Depanarea cu ajutorul consolei este o activitate banală pentru un programator.

Boo boo!

Însă pentru cei care nu sunt programatori, deschiderea consolei pe anumite saituri foarte populare, îi poate speria. Este consola chiar periculoasă!? Și mai bine să te ferești de ea?

Ei, nu chiar. Consola este un utilitar pentru depanarea paginilor web, și în special al codului Javascript, care facilitează componentele interactive de pe un sait web. În acest scop, consola are acces la toate informațiile pe care le transmiți unui sait, inclusiv cookie-uri, stocarea locală sau istoric. Desigur și tu ca utilizator al aplicației de browser (navigator) ai access la toate aceste informații fiind stocate la tine pe calculator.

Dar fiind un utilitar pentru depanare consola, de asemenea permite transmiterea acestor informații către alte saituri. Cookies și localStorage sunt date private, care pot fi folosite pentru clonarea sesiunii unui utilizator - similar cu operațiunea de clonare a unui card bancar. Și cum vă puteți gândi, are fi păcat ca aceste informații să ajungă în posesia unor persoane rău-intenționate.

De aceea avertismentul asta vă și spune:

Aceasta este o funcţie de browser destinată dezvoltatorilor. Dacă cineva ţi-a spus să copiezi ceva aici pentru a activa o altă funcţie Facebook sau pentru a „sparge” contul cuiva, este o înşelătorie şi îi vei oferi acces la contul tău de Facebook.

Cu alte cuvinte, dacă nu aveți de făcut depanare, fie că sunteți dezvoltator sau nu, și cineva vă oferă indicații să deschideți consola să să copiați ceva coduri acolo, este cel mai probabil o înșelătorie, oricât de prietenoasă ar putea părea persoana respectivă. Facebook și alte platforme populare se confruntă zilnic cu mii de astfel de încercări de ”furt a credențielelor” sau credential theft cum sunt denumite.

Ce face un programator, de obicei în consolă

Cea mai frecventă activitate, unde consola vine în ajutor este depanarea erorilor, rezultate prin rularea diverselor scripturi:

De asemenea unele scripturi, care colectează statistici sau metrici de performanță nu au un efect vizibil pe pagină și atunci singura indicație că au rulat se vede doar prin mesaje de informație în consolă.

O altă acțiune frecventă, este rularea de cod Javascript - pentru a depana direct funcții sau obiecte specifice scripturilor. Însă, fiind in instrument destinat dezvoltatorilor, consola nu are limitări, sau sandboxing, și poate rula orice cod Javascript:

Așadar putem încărca scripturi din surse externe, rula funcții de care citesc datele din storage-ul local sau vedea conținutul modulelor cookie. Detalii importante pentru un programator care depanează, dar la fel de prețioase pentru un hacker care dorește să obțină controlul asupra unui cont de utilizator.

Așadar consola este ca un cuțit de pâine, indispensabil la masă, dar din neatenție, te poți și tăia.

Referințe:

• [EN] Console Wars Part 1: Hacks for Hackers

• [EN] Using JavaScript to hack the web

Atunci când proiectăm un API, una dintre cele mai importante decizii este metoda de autentificare pentru clienți. Fie aplicații interne - mobile sau desktop, sau dezvoltate de un public mai larg pentru API-uri deschise.

În ultimul deceniu, API-urile REST au devenit o abordare arhitecturală de facto pentru platformele moderne de aplicații web și mobile. Prin separarea nivelului de date și cel de prezentare, au permis sistemelor să scaleze la ordinul de milioane de utilizatori. Însă odată cu creșterea, distribuția și accesul la date a ajutat la stabilirea unor standarde, cu beneficii și limitări de securitate bine cunoscute. În acest articol voi discuta despre două dintre acestea:

Basic HTTP authentication

Așa cum îi spune numele această metodă de autentificare este una care folosește un mecanism foarte simplu: user și parolă trimise prin header-ul HTTP Authorization. Această metodă are avantajul de a fi foarte simplu de implementat, atât pe partea de server cât și pe cea de client prin adăugarea header-ului în cererile HTTP:

X-Client-Version: 1.34
Authorization: Basic YmFzaWMtYXV0aA==

Din păcate această metodă prezintă câteva dezavantaje, și aș dori să încep cu cele de securitate: utilizatorul și parola sunt trimise decriptate. Mai exact transpuse în base64. De aceea această schemă de autentificare este viabilă doar sub HTTPS - protocol care criptează datele în tranzit. O altă inconveniență a acestei scheme este faptul că pentru fiecare utilizator este nevoie să creezi o parolă, și deci dacă ai trei aplicații pentru aceeași organizație care au nevoie de acces la API, va fi nevoie să generezi trei utilizatori diferiți.

Cu toate acestea, ținând cont de ușurința în implementare și de faptul că poate fi gestionată pe server, este o strategia viabilă când este combinată cu alte nivele de securitate: HTTPS și access prin VPN, iar numărul de utilizatori ai API-ului este foarte mic, până la 100 de clienți.

Chei (API keys)

Cheile de acces, sunt o variantă mai flexibilă și prezintă două avantaje față de Basic auth:

• pot fi generate și revocate fără a fi necesar să generăm un utilizator nou

• pot fi criptate de client, și deci trimise criptate

Implementarea și gestionarea acestei strategii necesită cod pentru validarea cheilor, sau se poate folosi o soluție de API Gateway. Pentru clienți autentificarea este la fel de simplă ca și în cazul basic auth:

Desigur, în cazul în care este necesară criptarea credențialelor se mai adaugă și un pas de criptare:

La fel ca în cazul basic auth, credențialele pot fi interceptate dacă nu sunt criptate, și de aceea și autentificarea prin cheie API este considerată sigură doar dacă se comunică prin HTTPS.

Printre alte limitări ale acestor două strategii se numără și faptul că prin design nu suportă extinderea cu alte mecanisme de autentificare cum ar fi Multi-factor (MFA).

Voi reveni într-un articol viitor cu alte două strategii de autentificare, respectiv HMAC și OAuth. Acestea folosesc chei de criptare și oferă nivele superioare de securitate.

Referințe:

• [EN] HTTP basic authentication

• [EN] How to Use API Keys

Atribuții:

• Imaginea articolului a fost descărcată de pe Freepik.

Configurarea și depanarea rețelei sunt sarcini cruciale pe care un administrator de sistem le va efectua în mod frecvent. Și desigur, deseori vor apărea probleme de conectivitate între mașini. Vă invit să învățăm despre două comenzi pentru linux, care ne ajută să depanăm conectivitatea cu internetul sau cu alte mașini din rețea.

IP

Comanda ip este una cu multe funcționalități care ne ajută să aflăm informații și să modificăm configurații pentru diverse obiecte și interfețe de rețea identificate de sistemul linux, incluzând adrese de IP, rute sau tabele ARP. Sintaxa comenzii este următoarea:

ip <OBIECT> [COMANDĂ]

De exemplu pentru a afișa statusul conexiunii pe toate dispozitivele de rețea, rulăm ip link show :

Comanda ip poate configura și afișa detalii despre următoarele obiecte:

• link controlează statusul network device-urilor (din linux)

• address pentru a manipula adresele IP ale device-urilor

• route pentru intrările în tabelul de rutare (routing table)

• neighbor pentru intrările în tabelul ARP

Câteva exemple:

Comanda IP este una dintre cele mai la îndemână, foarte utilă pentru depanare. Dar pentru configurare, oferă o interfață de access la un nivel inferior, față de alte unelte. Pentru a configura o rețea, avem la dispoziție o unealtă mai avansată și anume nmcli:

nmcli

Network Manager este un proces (daemon) disponibil pe majoritatea distribuțiilor de linux, iar scopul său este de a oferi o interfață de nivel superior pentru a face configurarea rețelei mai facilă și mai ușor de automatizat.

Cel mai probabil, dacă folosești un desktop linux, ai interacționat deja cu interfața grafică a Network Manager (GUI), însă pentru servere, vom folosi clientul din linia de comandă, respectiv nmcli. Sintaxa este următoarea:

nmcli <OBJECT> [COMMAND] [ARGUMENTS]

Pentru parametrul object putem folosi dintre următoarele:

• general - afișează mesaj de status și permisiunile

• networking - afișează, activează și dezactivează rețeaua

• radio - afișează, activează și dezactivează WiFi și WWAN

• device - afișează sau dezactivează device-urile de rețea

• connection - pentru configurarea pofilelor Network Manager

Acest utilitar oferă foarte multe opțiuni, imposibil de acoperit într-un blog. Pentru asta vă recomand să consultați man pages: man nmcli-examples

La ce putem folosi nmcli:

Putem edita un profil de conexiune și în mod interactiv folosind nmcli connection edit [nume-conexiune]. Comanda set ne permite să configurăm parametri, print va afișa valorile setate, iar save va salva noile valori. Pentru a ieși din modul interactiv utilizăm comanda quit:

De asemenea modul interactiv beneficiază și de completare automată, la apăsarea tastei TAB.

Acestea sunt doar două dintre utilitarele disponibile pe linux, pentru configurarea și depanarea rețelei. La acestea se adaugă nslookup, ss și tracepath, dintre cele mai notabile. Și desigur universalul ping.

Referințe:

• [EN] RedHat: Network Automation for Everyone

• [EN] 17 Best Linux Networking and Troubleshooting Commands

Cu acest articol, deschid o serie pe tema securității. Le voi posta preponderent în ultima lună din an. Pentru că securitatea este foarte importantă, iar în decembrie știu că lumea - inclusiv eu - face planuri pentru la anul.

Supply chain attacks cum sunt denumite, sunt o serie de atacuri cibernetice care, spre deosebire de alte tipuri de atacuri - viruși, malware, ROP - nu au ca țintă directă software-ul. Ținta este dezvoltatorul și ecosistemul utilizat pentru dezvoltarea programelor.

Pachete și librării third-party

Aproape 99.99% dintre toate programele utilizate azi folosesc librării third-party, adică cod scris sau compilat de către alte persoane și organizații care nu sunt implicate direct în dezvoltarea respectivului program. De exemplu dacă eu dezvolt o aplicație pentru comerț pe internet, voi instala o librărie care să mă ajute să criptez datele pe care le trimit către procesatorul de plăți, deoarece ar fi un efort prea mare să scriu acea librărie de la zero. Și desigur, de aceea foarte multe limbaje de programare oferă unelte ca managere de pachete - care te ajută să cauți, instalezi și în unele cazuri să și auditezi o librărie externă.

Când folosești o librărie externă, toate datele pe care le procesează acea librărie pot fi subiectul unui atac, de aceea în funcție de importanța și impactul proiectului pe care lucrezi, reputația și măsurile de securitate pe care la adoptă dezvoltatorii și organizațiile care dezvoltă librării externe pot fi foarte importante.

Scenarii de atac

Cum am menționat mai sus adoptarea unor măsuri de securitate și analiză a codului sunt necesare, mai ales pentru librăriile care sunt folosite în sisteme de operare sau programe care fac tranzacții monetare. Scenariile de atac se înscriu de obicei în patru categorii:

Lipsa unei evaluări de securitate de rutină

O librărie externă care are o vulnerabilitate. Dezvoltatorul fixează această vulnerabilitate și anunță public, însă organizații care dezvoltă software care include această librărie amână actualizarea. Pe această amânare s-au bazat atacatorii care au ex-filtrat datele clienților companiei Equifax în 20171 .

Publicarea unei librării cu nume similar

Deși cu impact mai mic, profitând de bună-voința și politica permisivă a hub-urilor de pachete cu sursă deschisă, atacatorii încarcă copii ale unor pachete extrem de populare, la care adaugă cod malițios - dar cu o literă schimbată - de exemplu în loc de jQuery, jQwery. Mulți dezvoltatori, mai ales juniori, vor trece cu vederea diferența de literă, sau de multe ori acestea se prezintă ca având funcționalități extra față de original.

Acest tip de atac se numește typosquatting și cel mai relevant exemplu este cel al pachetului crossenv2, care a ajuns să fie descărcat de aproape 1000 de ori, în detrimentul pachetului original cross-env.

Compromiterea contului dezvoltatorului librăriei

De multe ori, unele librării populare sunt dezvoltate de oameni foarte pasionați, dar în același timp fac asta ca un hobby. Deși în majoritatea cazurilor își iau măsuri de securitate, se poate întâmpla ca, contul lor să fie compromis. Acest tip de atac este mai dificil de executat, deoarece persoana compromisă va anunța imediat pe alte canale că este o problemă. Așadar atacatorii sunt nevoiți să evite acest lucru și mai apoi să publice o versiune nouă a librăriei cu codul malițios - pe care dacă alți membrii îl auditează are șanse foarte mici să ajungă publicat.

În acest caz librăriile dezvoltate de o singură persoană sunt mai expuse, deoarece este nevoie de compromiterea unui singur actor. Dar mai ales codul pentru versiuni poate fi publicat fără un audit. Însă și companiile mari sunt expuse, iar măsurile de securitate luate sau evitate de angajați pot avea consecințe nefaste. Iar un exemplu notoriu este breach-ul suferit de compania SolarWinds prin compromiterea furnizorului FireEye3.

Utilizarea la scară globală a unei singure librării

Știți cum multe soluții software se laudă cu standarde înalte de securitate pentru că adoptă soluții recunoscute și aplicate și în cadrul altor sisteme. Una dintre punctele slabe provine tocmai din tendința dezvoltatorilor de software de a folosi cele mai populare soluții. Deși pe de o parte, șansa ca aceste librării să fie și cele mai sigure este mai mare, când 90% din infrastructura de internet folosește o anumită librărie, se dovedește că pariem prea mult pe aceste soluții, în ciuda faptului că există și alte soluții cu aceleași caracteristici. Un astfel de pariu, l-am pierdut în 2014, când a fost anunțată o vulnerabilitate în OpenSSL4, o librărie care criptează datele a peste 90% din traficul de pe internet.

Cum ne protejăm

Acest subiect ar merita un articol dedicat, dar ca dezvoltatori putem să aplicăm un minim de măsuri de securitate pentru proiectele și infrastructura pe care rulează:

• actualizări și audit-uri periodice de securitate

• audit pentru codul scris de dezvoltatori - pull requests și reviews

• folosirea metodelor de autentificare sigure: ssh keys, 2 factor authentication.

• servicii care scanează periodic codul și dependințele pentru vulnerabilități

Pentru companii, cele enumerate mai sus desigur, însă merită menționate și folosirea unui VPN și standarde de autentificare ca Fido și Passkeys. Alte resurse găsiți în lista de mai jos:

• Do your part to secure the open source supply chain

• Small World with High Risks:

  A Study of Security Threats in the npm Ecosystem

• Automated dependency updates built into GitHub - Dependabot

• Snyk Vulnerability Database

• Sonar Source SAST

Acronimul CAP vine de la Consistency, Availabilty and Partition tolerance, după teorema propusă de Eric Brewer1. Aceasta nu se referă doar la sistemele de baze de date, ci la sistemele distribuite în general și afirmă următoarele:

Este imposibil ca un sistem distribuit de stocare a datelor, să furnizeze simultan mai mult de două dintre urmatoarele trei garanții:

• Consistență: Fiecare citire primește cea mai recentă versiune sau o eroare.

• Disponibilitate: fiecare cerere primește un răspuns care nu este o eroare, fără garanția că acesta reprezintă cea mai recentă versiune.

• Toleranță la partiționare: sistemul continuă să opereze chiar daca un număr arbitrar de mesaje sunt pierdute sau întârziate în rețeaua dintre noduri.

Uitându-ne la aceste trei constrângeri este ușor de observat, de ce sunt imposibil de implementat. Însă în designul sau alegerea unui sistem baze de date se prioritizează de obicei două dintre ele:

• fie ai consistență și disponibilitate (CA), dar în cazul unei partiții între noduri sistemul va returna erori: MySQL, MariaDb2, SQL Server.

• (CP) consistență și toleranță la partiționare, fără garanția disponibilității: Hbase, MongoDb3, Redis, BigTable.

• (AP) disponibilitate și toleranță crescută, cu renunțarea la consistență: Cassandra, ScyllaDb4, Riak, CouchDb.

Legat de baze de date, mai două concepte importante de menționat: eventual consistency și ACID.

Eventual consistency - orice bază de date devine consistentă în urma unui eveniment, și respectiv toate nodurile care comunică între ele vor avea aceeași versiune. Și cum menționam consistența mai sus, care este sacrificată în cazul sistemelor AP (availability & partition tolerance), asta nu înseamnă că aceste sisteme nu au consistență, dar nu sunt proiectate să garanteze consistența datelor - devin consistente eventual.

De exemplu, în urma unei erori de rețea ireconciliabile, în care nodurile nu pot comunica unul cu celălalt - un server din Australia nu mai poate comunica cu cel din București, aceste sisteme vor returna valori diferite pentru clienții din Australia decât pentru cei din București. Odată restabilită conexiunea, cea mai recentă versiunea va fi distribuită între noduri.

Simlar cu o pană de curent la un datacenter, asta poate fi o problemă cu impact minor, pentru o aplicație de email. Însă în cazul unei aplicații pentru tranzacții financiare este innacceptabil să obții valori diferite pentru aceleași cereri. Și de aceea în acest caz se va alege un sistem CP (consistency & partition tolerance).

De asemenea să nu confundăm CAP cu ACID. Acesta din urmă specifică un mod de operare al tranzacțiilor, și este specific RDBMS-urilor5.

Când sunt importante limitările CAP?

Desigur, această ”clasificare” este irelavantă dacă aplicația încă în stadiul de dezvoltare cu baza de date pe un singur server (nod). Dar în momentul când va fi nevoie să scaleze la mai multe noduri, cu replicare și sincronizare, sau când volumul de date necesită adoptarea unei soluții alternative pentru baza de date, cunoașterea acestor limitări ne va ajuta să facem o evaluare solidă.

De asemenea, și bazele de date proprietare, pe care le lansezi în cloud, au aceste limitări plus detalii despre latență și consistență între datacenters. Pentru unele seturi de date, de exemplu, cazul în care monitorizezi nivelul apei unui fluviu - mai mult de 1 secundă de latență este inacceptabil.

Mai este relevantă CAP în 2023?

O întrebare validă, mai ales că această teoremă a fost publicată în 1998. Însăși autorul, Eric Brewer menționează că ”regulile s-au schimbat” într-un articol din InfoQ publicat în 20126.

Un alt articol7, din 2015 argumentează că ar trebui să abandonăm această clasificare, deoarece este de cele mai multe ori ambiguă și în funcție de vendor poate fi interpretată.

Eu cred că aceste concepte sunt importante, și utile de știut chiar dacă aplicabilitatea lor este mai puțin relevantă în ziua de azi. CAP pornește cu o serie de întrebări ”ce se întâmplă dacă…?”, și ne amintește despre limitările de care le vom întâlni când proiecteăm sisteme distribuite.

Large language models, piatra de hotar a inteligenței artificiale pe care o vedem azi integrată cu tot mai multe aplicații, sunt rețele neuronale învățate să recunoască dar mai ales să determine statistic componente care preced sau succed input-ul în limbaj natural. O să revin cu un articol mai detaliat pe tema aceasta, dar azi o să vorbim despre un proiect foarte interesant - Ollama, care îți oferă posibilitatea de a rula astfel de modele pe PC-ul personal, sau pe un server din cloud dacă ai la dispoziție unul dotat.

Docker pentru LLMs

Momentan disponibil pentru Mac, Linux și Windows/WSL, Ollama este un fel de docker în care poți rula modele pre-antrenate cu miliarde de parametri. Desigur vei avea nevoie de resurse, mai ales de RAM - minim 16 GB deoarece modelele vor folosi cel puțin jumătate din ei:

• 8 GB RAM pentru modelele cu 3 miliarde de parametrii

• 16 GB RAM pentru cele cu 7 miliarde

• 32 GB pentru cele cu 13 miliarde

Pe linux și WSL2 instalarea este foarte simplă, și putem rula un model local care lansează un prompt în trei pași:

# Instalare
curl https://ollama.ai/install.sh | sh

# Rulează, modelul llama2
ollama run llama2

# Prompt
>>>

Alte modele disponibile sunt mistral, codellama, vicuna, starcoder, orca-mini, xvinlm.

Http API /generate

Ollama expune și un API pe protocolul http, prin care poate fi integrat cu alte servicii sau aplicații care deja suportă integrări cu modele AI (de exemplu Obsidian), pentru generare de text:

curl -X POST http://localhost:11434/api/generate -d '{
  "model"  : "llama2",
  "prompt" : "Why is the sky blue?"
}'

Oferă și un API pentru a genera embeddings:

curl -X POST http://localhost:11434/api/embeddings -d '{
  "model"  : "llama2:7b",
  "prompt" : "Here is an article about llamas..."
}'

Și unul pentru a crea modele pornind de la un model de bază:

curl -X POST http://localhost:11434/api/create -d '{
  "name": "mario",
  "path": "~/Modelfile"
}'

Modelfile

Simlar cu conceptul de Dockerfile, cu ajutorul unui Modelfile poți tuna comportamentul și alți parametrii specifici unui model:

FROM llama2
# Configurează parametrul 
# Valoare mai mare - creativ, valoare mică - coerent
PARAMETER temperature 1

# Configurează dimensiunea ferestrei de context 4096, 
# Câte token-uri va folosi modelul pentru context, la generarea 
# token-ului următor
PARAMETER num_ctx 4096

# Pornește cu un prompt specific, 
# Pentru a ghida răspunsurile oferite de asistent
SYSTEM You are Mario from super mario bros, acting as an assistant.

Cu acest fișier, creăm și rulăm un model configurat:

ollama create mariobros2 -f ./Modelfile
ollama run mariobros2

Promptul se va lansa cu un chatbot, care va răspunde ca și când ar fi personajul Mario.

Un altă aplicație interesantă este cea a unui ChatGPT local, sau PrivateGPT:

Surse:

• Code to the Moon (Video)

• www.ollama.ai

• github.com/jmorganca/ollama

• github.com/kevinhermawan/Ollamac

• github.com/jmorganca/ollama/blob/main/docs/modelfile.md