Douăzeci și nouă de sisteme, descrise cu sinceritate.

Django 5.2, PostgreSQL și MariaDB, randare pe server, fără SPA. Aproximativ 120 de modele în paisprezece aplicații și 170 de șabloane. Deploy pe găzduire partajată sub Passenger, cu cron în loc de Celery, pentru că acolo niciun proces de fundal nu supraviețuiește.

Conversions API pe server, cu deduplicare față de Pixel-ul din browser pe un event id comun, date personale hashuite, trimise pe un thread de fundal și cu fail-open. Drivere de imprimantă fiscală cu un mod degradat pe driver null, așa că un dispozitiv inaccesibil marchează bonul ca fiind în așteptare în loc să blocheze vânzarea. Un API cu bearer token pentru un client Windows de pontaj aflat în afara repository-ului, care încarcă instantanee de activitate minut cu minut. Un sistem de roluri rezolvat pe priorități - superuser, apoi grup, apoi fișa de angajat al clinicii - care alimentează zece dashboard-uri diferite dintr-o singură bază de cod.

Django 5.2, PostgreSQL, Stripe, page builder GrapesJS în admin. Douăzeci și cinci de modele în patru aplicații care conțin modele.

Backend-ul AI stă în spatele unui singur tip de rezultat normalizat, cu trei implementări interschimbabile - mock, API găzduit și self-hosted - alese printr-o singură variabilă de mediu, așa că întregul produs rulează cap-coadă fără niciun furnizor AI atașat și fără modificări de cod. Un pipeline clinic de încărcare → analiză → constatări → plan de tratament → linii de deviz, fiecare constatare purtând propria bandă de încredere. Middleware de atribuire first-touch care captează patru click id-uri de la platforme de publicitate într-un raport de funnel de la lead la client plătitor.

Django 5.2, MySQL, modeltranslation în trei aplicații, CKEditor 5, builder de landing-uri GrapesJS.

O mașină de stări de la cerere la aprobare pentru programări: cererea unui vizitator rămâne în așteptare până când personalul o aprobă, moment în care se creează sau se potrivește o fișă de pacient și se materializează o programare reală. Fiecare lead își stochează răspunsurile de două ori - ca JSON și ca rânduri individuale - alături de IP, user agent, referrer, geografie și setul complet de UTM-uri și click id-uri Meta. Landing-urile de campanie sunt montate în afara rutării cu prefix de limbă, așa că traficul plătit nu ajunge niciodată pe un redirect de locale.

Django 5.2 cu DRF și JWT, PostgreSQL, Celery și Redis, hashing Argon2, patruzeci și nouă de aplicații locale. React cu Vite și Tailwind în față, Flutter pentru mobil. Sentry, gunicorn cu gevent.

Un motor de recomandare care evaluează șapte stări ale sistemului nervos dintr-un check-in, aplică filtre stricte de eligibilitate, comprimă prioritatea într-o bandă de șase puncte, astfel încât contextul să bată popularitatea, și apoi eșantionează prin softmax în loc să ia argmax-ul - așa că întregul catalog rămâne accesibil, în loc să se prăbușească pe aceleași douăzeci de elemente. Un al patrulea slot este rezervat descoperirii și eșantionat după recență. Rulează pe interogări brute prin driver, nu prin ORM, pentru că se execută pe fiecare ecran. Retrieval-ul este ancorat în aproximativ treizeci de mii de soluții structurate extrase din circa nouăzeci și cinci de cărți, cu un prompt care îi interzice modelului să răspundă din propria cunoaștere generală și cu o ramură explicită pentru situații de criză. Un harness Monte Carlo rulează motorul real peste sesiuni sintetice - cincizeci de mii de check-in-uri într-o rulare, șaptezeci de mii de sesiuni echilibrate în alta - verificând că nicio stare de criză nu primește un card nepotrivit și că niciun card nu rămâne inaccesibil. A scos la iveală și o breșă reală de detecție, ceea ce este chiar rostul unui harness. Alegerea furnizorului și fiecare cheie de API se rezolvă dintr-un tabel editabil din admin, înainte de a cădea înapoi pe variabilele de mediu, așa că furnizorii și cheile se rotesc fără deploy.

Django 5.2 LTS cu django-unfold, MySQL prin PyMySQL, Redis, Celery cu beat și rezultate, Strawberry GraphQL, modeltranslation pe șapte limbi, segno pentru codurile QR, un bundle React construit cu Vite și urcat deja compilat. Douăzeci și șase de aplicații, optzeci și două de modele.

Discountul este o linie în registru, nu o modificare de preț: fiecare promoție scrie o linie separată pe comandă, cu eticheta ei și cu cine a aprobat-o, așa că închiderea de zi vede exact cât s-a dat la reducere, iar o reducere nu poate fi confundată cu un preț mai mic. Consumul de stoc rulează pe rețetă la fiecare vânzare, și pe articol, și pe fiecare opțiune adăugată, pentru că laptele vegetal nu costă cât cel obișnuit, și scrie mișcări de stoc - de aceea inventarul produce o variație în bani față de teoretic, nu o simplă diferență de bucăți. Casa de marcat nu folosește conturi de Django: un barista se autentifică pe tabletă cu un PIN de patru cifre, pe o sesiune proprie, separată de cea de admin, pentru că o parolă de administrator tastată pe un ecran din tejghea este exact felul în care se pierde un cont. Aplicația clientului nu cere cont deloc - codul QR de pe masă deschide meniul, iar comanda plecată de acolo ajunge pe ecranul din bucătărie cu eticheta mesei pe ea.

Django 5.1, MySQL în producție, cu PostgreSQL și SQLite ca variante de rezervă pentru dezvoltare, Celery și Redis cu fallback eager, blocare cu django-axes, profilare cu Silk, builder GrapesJS. Patruzeci de modele în șase aplicații.

Finalizarea plății este dublată intenționat și idempotentă - aceeași rutină rulează din webhook-ul Stripe și din pagina de retur, ieșind devreme dacă rezervarea este deja plătită, așa că un webhook pierdut nu poate pierde o rezervare plătită. Channel manager-ul nu oferă nicio schemă de semnătură pentru webhook-uri, așa că endpoint-ul este autentificat printr-un secret aflat în calea URL-ului, cu un test care îl setează gol ca să demonstreze că este fail-closed. O mașină de stări de rezervare trimite sejururile confirmate pe canalul direct și blocările pe unul separat; proprietatea fără id de canal este potrivită local, după slug. Fiecare email trimis este salvat înainte de livrare de un backend de mail scris pe măsură.

Django 5.1, MySQL, Celery cu fallback eager și Redis opțional, admin Unfold cu un studio inclus în repository, HTMX și Alpine peste Tailwind. Aproximativ patruzeci de modele în zece aplicații. Flutter pentru ambii clienți mobili, JWT în secure storage.

Un checkout în desfășurare este ținut ca rezervare temporară și promovat la una reală abia când Stripe confirmă sesiunea, așa că un checkout abandonat nu blochează niciodată stocul. Șase tipuri distincte de documente fiscale împart mixin-uri comune pentru părți și pentru linii, în loc să fie un singur model de factură cu un flag de tip. Fișele de oaspeți se reconciliază între canale printr-un strat de oaspete canonic, cu registre separate pentru persoane fizice și pentru companii, așa că aceeași persoană care vine de la un OTA și dintr-o rezervare directă este o singură fișă. Fiecare secret de integrare se rezolvă întâi din baza de date, cu un cache de șaizeci de secunde, așa că cheile se rotesc live.

Django 5.0, MySQL, modeltranslation pe opt limbi, Tailwind și Alpine din CDN, fără pas de build. Treizeci și opt de modele.

Confirmarea rezervării printr-un cod de șase cifre trimis pe email, cu limitare de rată per IP, plafon de cinci încercări, expirare în cincisprezece minute și cooldown la retrimitere. Token-uri semnate și limitate în timp îi dau unui vizitator anonim acces la propria pagină de rezervare timp de douăzeci și patru de ore, fără cont. Prețul este recalculat pe server la fiecare salvare, dintr-un tabel cu cinci praguri de zile încrucișat cu nivelul de asigurare, cu discountul aplicat doar pe subtotalul de închiriere - niciodată preluat pe încredere de la client.

Django 5.1, MySQL, Redis și Celery, DRF cu JWT și OpenAPI, admin Unfold, modeltranslation și parler. O aplicație React 19 construită cu Vite și livrată deja compilată. Paisprezece aplicații, șapte limbi cu cataloage de traducere complete.

Scorarea lead-urilor cu un model de limbaj care caută pe web: răspunsurile din formular, UTM-urile, click id-urile, rezultatul autentificării și statusul do-not-call sunt adunate într-un dosar și punctate într-o bandă, cu o justificare și o acțiune recomandată, folosind o cheie per client. Un stack de conformitate în trei părți - scrub complet cu detectarea tipului de linie și a numerelor mobile, verificare de litigator și căutare de număr realocat față de data consimțământului. Tenantul este rezolvat din header-ul Host, cu un cache de cinci minute, iar fiecare trimitere de formular este reverificată față de clientul acelui host, așa că un lead care trece dintr-un tenant în altul este imposibil structural. Builder-ul de formulare stochează un HMAC al fiecărui cod de verificare, nu codul în sine, iar fiecare bifă de consimțământ scrie o înregistrare imutabilă cu textul exact, IP-ul și URL-ul.

Django 5.2 cu Wagtail, două depozite de date - PostgreSQL pentru starea operațională și ClickHouse ca firehose de tracking - Redis, Celery cu beat și Flower, DRF plus un strat JWT scris de mână pentru mobil. Patruzeci și șase de modele numai în aplicația de bază.

Fiecare furnizor se mapează pe unul dintre trei sub-scoruri - contactabilitate, autenticitate, intenție - rulate în paralel printr-un thread pool și mediate într-o notă compozită, cu ponderi reglabile din admin. Adaptoarele care dau eroare sau sar peste ies din numitor, în loc să primească zero, iar orice adaptor blocant impune direct nota cea mai mică. Setul de semnale include biometrie comportamentală, amprentare TLS, adâncimea derulării și ritmul de completare a formularului, alături de trei sub-semnale de la modele de limbaj. Direcționarea către cumpărători filtrează după credit, program de lucru, capacitate zilnică și săptămânală, verticală și geografie, apoi departajează după încărcarea din ultimele douăzeci și patru de ore, înainte de prioritate. Fiecare apel către un furnizor scrie un rând de log cu endpoint, status și rezumatul răspunsului, tocmai ca să se poată reconcilia costul de furnizor per lead.

Flutter cu Riverpod, Dio și go-router, secure storage pentru token-uri. O aplicație Django însoțitoare care expune registrul admin-ului ca REST.

Permisiunile nu sunt reimplementate: API-ul mapează verbele HTTP pe permisiunile proprii ale Django - view, add, change și delete - iar căutarea, paginarea și ordonarea listelor vin direct din configurația fiecărei clase de admin. Adăugarea unui model în admin-ul Django îl adaugă în aplicația mobilă. O aplicație-soră pentru cumpărători oglindește cele paisprezece seturi de teme per client din aplicația web, citind-o pe cea activă la autentificare și punând-o în cache, ca să nu apară la pornirea la rece un flash cu brandul greșit.

Django 5.2 cu Wagtail, MySQL, Redis, Celery cu beat, Channels și Daphne pentru WebSockets, DRF cu JWT, pandas și numpy, web3 pentru canalul crypto. Flutter și Dart pentru clienții mobili și desktop, un singur lib/ împărțit de toți trei. Șaptesprezece limbi configurate.

Șapte citiri independente de indicatori pe fiecare timeframe, iar un timeframe este de acord doar când cel puțin cinci din șapte concordă - apoi, peste asta, confirmare pe mai multe timeframe-uri, cu filtre opționale de candlestick și de știri și cu stopuri și ținte derivate din ATR. Fiecare trecere scrie un rând de audit, indiferent dacă a produs sau nu un semnal, iar dry-run este comportamentul implicit. Canalul de plată crypto nu ține nicio cheie privată pe server: o sarcină programată urmărește lanțul pentru transferuri către o adresă de încasare, potrivește depunerile în așteptare după sumă și confirmă după douăsprezece confirmări. Două middleware-uri suprapuse fac produsul inaccesibil până când onboarding-ul este cu adevărat complet.

Django 4.2, MySQL, admin Unfold cu un dashboard pe Chart.js, modeltranslation pe opt limbi, Tailwind și Alpine din CDN. Șaizeci și două de modele în nouă aplicații, șaizeci și trei de tabele.

Lanțul de fulfilment este real, nu declarativ: generarea AWB-ului loghează cererea completă, răspunsul și eroarea pe comandă, iar facturarea emite documente și storno pe aceeași comandă. Prețul în două valute stochează suma nativă și suma afișată ca pereche, nu o sumă și un curs, așa că o comandă din trecut nu se reevaluează pe tăcute când se mișcă cursul de schimb.

Django 4.2, MySQL, admin Unfold, ReportLab cu un font înregistrat special pentru compunerea PDF-urilor. Cincizeci și cinci de modele.

Corpul contractului este un șablon juridic structurat care se numerotează automat, fixează datele beneficiarului la momentul semnării și validează că un contract este legat fie de o persoană fizică, fie de o companie, dar niciodată de ambele. PDF-urile de ofertă sunt compuse cameră cu cameră - opt tipuri de încăpere, fiecare cu descrierea, prețul și fotografiile ei - ca document paginat, nu ca șablon completat. Fiecare sumă este stocată în ambele valute, pe coloane paralele.

Django 5.2, MySQL, admin Unfold cu șabloane proprii de calendar și de fișă de pontaj. Clientul desktop este Tkinter - aproximativ 1.600 de linii - împachetat cu PyInstaller într-un singur executabil și livrat printr-un installer.

Partea interesantă este logica de ieșire automată din tură: o sesiune se închide la ultimul ei heartbeat abia după ce a trecut sfârșitul de program și nu a mai sosit niciun heartbeat timp de zece minute - iar un heartbeat ulterior, care poartă un timestamp de aplicație activă, poate readuce la viață o sesiune închisă de o pană reală. Asta este o problemă de stare distribuită tratată corect, nu un cron de noapte care ghicește.

Laravel 11 cu Breeze, MySQL, Blade cu Vite, Tailwind și Alpine, DomPDF. Unsprezece modele, optsprezece migrări.

Nimic neobișnuit din punct de vedere arhitectural și nici nu are de ce să pretindă altceva: este un instrument intern mic și corect. Partea de substanță este dashboard-ul de pipeline, care agregă numărul de prospecți pe tip de spațiu și destinație, distribuția pe intervale de suprafață și bugetul mediu față de valoarea totală și de cea încasată a proformelor.

Django 4.2, MySQL, admin Unfold, modeltranslation pe zece limbi, Tailwind și Alpine. Aproximativ treizeci de modele. Un plugin însoțitor pentru un instrument de design, în afara runtime-ului Django.

Pipeline-ul ia codul sursă lipit, generează din el diagrame de arhitectură și de flux, apoi construiește o specificație de ecrane și paletă pe care un plugin de instrument de design o preia și o desenează ca frame-uri reale, editabile. Este un instrument mic, dar elimină cea mai neplăcută oră de la începutul oricărui proiect.

Doar biblioteca standard din Python. Fără framework, fără dependențe, fără pas de build, aproximativ 920 de linii. Serverul este chiar serverul HTTP din biblioteca standard, cu o coadă de joburi pe thread-uri.

Tratează corect autentificarea pe două niveluri a furnizorului - credențiale de serviciu pentru a emite credențiale de client, apoi credențiale de client pentru generare, ținute în cache și reutilizate - și tratează generarea ca fiind cu adevărat asincronă, interogând fiecare job pe thread-ul lui, cu timeout. Dacă nu sunt configurate credențiale, interfața dezactivează generarea și spune asta, în loc să eșueze abia în momentul folosirii.

PHP și Laravel 8 cu Jetstream și Livewire, MySQL, șabloane Blade, Laravel Mix care construiește Tailwind, Bootstrap, jQuery, Alpine și Sass. Treisprezece modele, douăzeci și nouă de migrări, treizeci și două de controllere, Apache pe cPanel.

Traducerea stă în schemă, nu într-un pachet: modelele de articol, magazin, galerie și meniu poartă fiecare câte patru seturi paralele de coloane, unul pe limbă, iar româna a apărut la cinci ani după lansare, prin migrări care le lărgesc pe toate. Este un design mai brut decât un tabel de traduceri și are o singură virtute reală - citirea unui rând tradus este exact aceeași interogare ca citirea unuia netradus, fără join și fără logică de fallback pe care s-o greșești. Merită spus direct: acesta este un monolit CRUD convențional, pe un stack care s-a învechit. Ce demonstrează nu este ingeniozitate, ci faptul că a fost întreținut discret ani la rând după predare.

Django 4.2, MariaDB, admin Jazzmin cu inline-uri imbricate, modeltranslation și Rosetta pentru editarea traducerilor direct în browser, Bootstrap și AOS. Treizeci de modele. Patru containere: nginx, web, baza de date și un scheduler.

Expeditorul de campanii calculează câte intervale au trecut de la ora de start și trimite următorul lot de zece destinatari, urmărind progresul și scriind un log de livrare cu un message id generat pentru fiecare destinatar - o limitare gândită să supraviețuiască pe un server de mail partajat, nu să presupună existența unui furnizor de livrare. Apoi o sarcină orară interoghează IMAP, parsează notificările de respingere și le reconciliază înapoi cu acele loguri de livrare, după message id. Dedesubt, protecție anti-abuz în straturi: capcane de tip honeypot pe URL-uri, care blochează IP-ul sursă timp de treizeci de zile, o listă neagră de boți și limite de rată pe fiecare view.

HTML static cu Tailwind compilat într-o singură foaie de stil, module de JavaScript simplu, un singur endpoint PHP pentru formularul de contact. Apache pe găzduire partajată.

Endpoint-ul de mail vorbește SMTP direct - deschide un socket TLS și face singur handshake-ul de autentificare, fără nicio bibliotecă de mail - pentru că gazda nu oferea nicio alternativă utilizabilă. Analiza de trafic chiar pornește de la consimțământ: tag-ul nu se încarcă deloc până când consimțământul nu este salvat, respectă în plus Do-Not-Track și refuză să ruleze în afara hostname-ului de producție. Sensul de la dreapta la stânga este tratat în sursa Tailwind, nu lipit ca a doua foaie de stil, iar fiecare URL își declară alternativele de limbă.

Django 4.2, MySQL, admin Unfold, modeltranslation. PayPal apelat direct prin REST, nu printr-un SDK.

Un tipar de CMS pe modele singleton, în care fiecare dintre cele aproximativ douăzeci de secțiuni de pagină își creează singură rândul la migrare, așa că un editor nu deschide niciodată admin-ul pe un ecran gol și nu trebuie să știe ce este un fixture. Toate cheile de la terți stau într-un seif din baza de date, nu în fișiere de mediu, ceea ce este compromisul corect pentru un client care schimbă furnizorii mai des decât face deploy.

HTML static. Fără framework, fără bază de date, fără pas de build - răspunsul corect pentru un catalog care se schimbă de două ori pe an și trebuie să trăiască mai mult decât fereastra de suport a oricărui framework.

Nimic, și tocmai asta este ideea. Nu orice cerință este un sistem, iar un site static pe care clientul îl poate găzdui oriunde timp de zece ani este aici un rezultat mai bun decât un CMS în care nu se va autentifica nimeni.

Django 4.2 cu django-unfold, MySQL prin PyMySQL, modeltranslation pe opt limbi, CKEditor pentru câmpurile lungi, Tailwind și Alpine încărcate dintr-un CDN, fără pas de build, Whitenoise, Passenger pe cPanel. Treizeci și două de modele în trei aplicații.

Nimic de aici nu este dificil, iar intrarea își merită locul demonstrând abilitatea opusă: un site al cărui proprietar nu are nevoie niciodată de un dezvoltator ca să schimbe un cuvânt din el. Defectul, spus cinstit, se vede în schemă - modelul de portofoliu poartă în continuare un câmp de suprafață și unul de locație, moștenite din șablonul imobiliar din care a fost forkuit, iar aproximativ o treime din lista de dependențe este preluată de acolo și nu este importată niciodată. Exact atât costă, de fapt, să forkuiești un proiect care funcționează ca să câștigi o săptămână, și prefer să arăt asta decât să o scot din poveste.

Vue 3 cu Composition API, Vue Router, Vite cu chunking manual al dependențelor, Tailwind, GSAP, iconițe Lucide. Aproximativ șase mii trei sute de linii în opt rute, dintre care una este o pagină de design system. Apache servește rezultatul build-ului.

Douăsprezece componente de animație, câte una pentru fiecare serviciu, scrise, nu luate dintr-o bibliotecă, cu composable-uri de intersection observer și de numărare crescătoare dedesubt. Este muncă de meșteșug și asta e toată ambiția ei. Poartă și cel mai clar exemplu pe care îl am de dependență care își supraviețuiește scopului: reCAPTCHA v3 se încarcă pe fiecare pagină și nu păzește nimic, pentru că pe site nu există niciun formular - ruta de contact este un link mailto, iar biblioteca de validare instalată pentru formularul care nu a fost construit niciodată este în continuare în manifest. Un script de la terți care rulează la fiecare încărcare de pagină și nu face nimic este o problemă de consimțământ, nu o rămășiță inofensivă, și este pe lista de eliminat.

Solidity 0.8.24 cu OpenZeppelin 5.1 fixat exact, Hardhat și ethers v6, Node 20 pentru relayer și pentru faucet, Terraform și Docker Compose pentru flota de validatori, un stack Blockscout inclus în repository, în spatele nginx, pentru explorer, JavaScript simplu pentru dApps și pentru wallet, Rust și Anchor pentru ramura Solana. 3.500 de linii de Solidity original, 12.000 de JavaScript, 142 de teste de contract în patru suite.

Un singur fișier de alocare este sursa unică de adevăr pentru cele o sută de milioane de unități de ofertă, iar build-ul generează din el genesis-ul, directoarele de compose pentru fiecare rol și scripturile de deploy, la fel pentru devnet, testnet și mainnet - așa că cele trei rețele nu pot să se desincronizeze. Un pas de preflight refuză să construiască un genesis de mainnet cât timp mai există vreo adresă de tip placeholder. Faucet-ul reimplementează protocolul WebSocket propriu al clientului de nod, ca pagina să nu aibă nevoie de niciun caz special pentru rețelele locale. Relayer-ul își avansează cursorul de blocuri abia după ce fiecare mesaj dintr-un interval este salvat, pentru că, dacă avansează întâi, pierde transferurile definitiv și nimic nu rescanează. Conservarea ofertei este un invariant de proiectare, nu o verificare: exact un lanț ține în escrow și toate celelalte emit, plafonul token-ului este egal cu oferta de la genesis, iar scripturile de deploy nu emit nimic. Versiunea de OpenZeppelin este fixată pentru că 5.2 emite un opcode mai nou decât EVM-ul nodului - o bibliotecă mai nouă ar produce bytecode pe care propriii lui validatori nu l-ar putea executa. Bridge-ul este un bridge cu cvorum de încredere și este descris ca atare în trei locuri diferite, în loc să fie numit trustless.

Python 3.11 cu pandas și numpy, cu versiuni limitate intenționat, ca wheel-urile precompilate să se instaleze pe găzduire partajată fără compilator. SQLite pentru jurnalul de tranzacții, MySQL pentru export, chiar serverul HTTP din biblioteca standard pentru dashboard. 18.000 de linii în 94 de module și 541 de teste.

Modelul de limbaj rulează pe propriul lui ceas de fundal și scrie un cache pe care bucla de tranzacționare îl citește instantaneu, pentru că un dus-întors de una până la trei secunde pe bare de cinci secunde înseamnă să acționezi pe un preț care nu mai există - iar acest eșec este silențios, pentru că răspunsul continuă să pară rezonabil. Poate emite un bias și doi multiplicatori; nu poate inventa o tranzacție, nu poate alege o direcție, nu poate dimensiona o poziție și nu poate muta un stop, iar la eroare cade pe neutru. Stratul de învățare este o regresie logistică scrisă de mână tocmai ca să nu poată ascunde overfitting-ul: in-sample și out-of-sample sunt raportate mereu împreună, împărțirile respectă ordinea în timp și, alături, se tipărește o linie de bază naivă care ia fiecare tranzacție. Ieșirile se declanșează pe prețul activului suport, nu pe prima opțiunii, pentru că prima se mișcă din volatilitate și din trecerea timpului. Supervizorul folosește un lock pe fișier, după ce două rulări pornite la câteva secunde una de alta au trecut de o verificare pe pidfile și au lăsat doi boți să tranzacționeze pe același cont.

Django 4.2, django-unfold, MySQL, modeltranslation pe zece limbi, CKEditor, Tailwind și Alpine dintr-un CDN, Passenger pe cPanel. Treizeci de modele în trei aplicații, plus un plugin Figma însoțitor.

Generatorul pentru Figma își construiește arborele de noduri determinist - frame-uri, dreptunghiuri și text așezate prin cod - și abia apoi oferă o trecere opțională printr-un model, ca să înfrumusețeze rezultatul. Ordinea asta este întregul design: același proiect produce mereu același layout, iar modelul poate îmbunătăți rezultatul, dar nu este niciodată motivul pentru care există. Plugin-ul își ia specificația printr-un URL de admin semnat, așa că aplicația desktop Figma poate trage un design fără să dețină o sesiune. Două lipsuri pe care nu am de gând să le prezint ca terminate: partea de push a integrării cu Figma este încă un stub, iar clientul OpenAI este importat fără să fie fixat în dependențe, așa că o instalare curată a acelui panou eșuează până când este adăugat.

Python 3.11 și Django 5.2 LTS, django-unfold, MySQL prin PyMySQL, Redis, Celery cu beat, rezultate și Flower, Strawberry GraphQL cu extensia de optimizare pentru Django, modeltranslation, Silk doar în dezvoltare, React 18 și Vite pentru insula de front-end. Zece aplicații, treizeci și trei de modele, aproximativ opt mii două sute de linii de Python.

Urmărirea conversiilor se declanșează de două ori, intenționat: pixelul din browser și API-ul de pe server trimit același eveniment sub același event id, așa că platforma le deduplică, iar evenimentele pe care ad blocker-ele le-ar elimina altfel - de regulă între o cincime și două cincimi din ele - supraviețuiesc. Câmpurile personale sunt hashuite înainte să plece, iar o eroare de tracking este înghițită, nu ridicată, pentru că un lead valorează mai mult decât unul raportat perfect. Motorul de formulare înseamnă nouă modele și douăsprezece tipuri de întrebare peste un funnel cu cinci stări, cu o urmă de audit pe evenimente; endpoint-urile lui publice sunt scutite intenționat de CSRF, pentru că markup-ul este scris în admin și servit ca atare, iar un id de sesiune emis de server și imposibil de ghicit face treaba pe care ar fi făcut-o token-ul. Fiecare constrângere de versiune din fișierul de dependențe poartă motivul pentru care există, inclusiv cele de care aș prefera să nu am nevoie. Punctul slab este acoperirea cu teste: douăzeci și trei de teste de fum la opt mii de linii, ceea ce nu este suficient și știu asta.