Software · explicații · fotografie
Aplicații, jocuri și instrumente.
Cu explicațiile din spatele lor.
Sunt Sergiu Dogotaru, dezvoltator software cu experiență în frontend enterprise. Aici găsești lucruri construite, exemple despre cum funcționează și întrebări care merită urmărite mai departe.
Interfețe care trebuie să evolueze
Lucrez cu React și TypeScript, dar munca nu se oprește la ecran: include integrarea cu API-uri, componentele comune, verificarea și livrările succesive. Am lucrat pe termen lung la frontend-uri enterprise și la aplicații interne; separat, dezvolt proiecte proprii prin Panda Systems.
Un filtru nou pare o modificare mică. Într-o aplicație existentă, el trebuie să se potrivească cu datele primite, să păstreze selecția și să aibă un comportament clar când nu există rezultate. Este un exemplu simplificat al relațiilor care trebuie urmărite dincolo de aspectul unui control.
Selecția din interfață
Ce rămâne activ după schimbarea unui rezultat sau după întoarcerea în pagină? Selecția trebuie să fie clară, nu doar memorată undeva.
Cererea către API
Ce valoare trimitem și cum reprezentăm lipsa filtrului? Interfața și serviciul trebuie să vorbească despre aceeași selecție.
Comportamentul următor
Dacă filtrul se schimbă în timpul încărcării, ce rezultat mai este relevant? Un rezultat gol și o eroare cer răspunsuri diferite.
Ce poți afla despre un nivel fără să-l joci?
Într-un joc cu piese care cad, o mutare poate porni o succesiune: potrivire, dispariție, cădere, altă potrivire. Ca să înțelegi rezultatul, trebuie să poți urmări pașii, nu doar tabla de la început și de la sfârșit.
Ilustrație de concept, nu captură a instrumentului.
Am construit un workbench React/TypeScript pentru editare, validare și simularea regulilor unui joc Match-3, în afara editorului principal. Instrumentul ajută la examinarea configurației și a comportamentului modelat. Nu stabilește singur dacă nivelul este interesant pentru un jucător.
Format valid sau sens păstrat?
Exemplu sintetic: obiectivul cere 8 piese roșii și 5 albastre, iar ordinea culorilor nu contează. „5 albastre, 8 roșii” păstrează obiectivul; „5 roșii, 8 albastre” îl schimbă. Ambele variante pot respecta același format. La import și export nu ajunge ca fișierul să fie acceptat: trebuie păstrat și sensul configurației.
Mai multe surse nu înseamnă automat mai multe dovezi
O informație poate trece dintr-o notă într-un rezumat și apoi într-o prezentare. Repetarea îi mărește vizibilitatea, nu și numărul confirmărilor independente. Merită urmărit nu doar unde apare o afirmație, ci și ce observație o susține.
Exemplu fictiv
- Nota inițială: „Prototipul a fost demonstrat într-un mediu de test.”
- Rezumatul: „Soluția a fost realizată.”
- Prezentarea: „Produsul este disponibil.”
Dacă ultimele două texte derivă din primul, nu avem încă dovada unei lansări. Descrierea a devenit mai puternică decât observația de la care a pornit.
Dar sursa inițială este sigur corectă?
Nu. Originea ajută la verificare; nu garantează adevărul sau actualitatea. Contează și ce spune efectiv documentul, la ce moment și pentru ce concluzie îl folosim.
Panda KB oferă un context concret pentru această discuție: o bază de cunoaștere, un mecanism de căutare și un asistent care trebuie să păstreze distincția dintre un fragment găsit și o concluzie susținută.
Ce se schimbă când baza jocului există deja?
Startup Match și Shiba Sushi sunt dezvoltate prin extinderea unui kit comercial Match-3. Contribuția mea include comportamente de gameplay, conținut, instrumentare și separarea dintre logica comună și prezentare.
O captură arată cum arată jocul, nu tot ce trebuie să funcționeze: continuarea unei cascade, încheierea unei runde sau încărcarea conținutului. Reutilizarea unei fundații și realizarea unui produs sunt două lucruri legate, dar nu identice. Motorul de bază și o parte din asset-uri sunt third-party; lucrarea descrie extensiile și produsizarea.
Și fotografie, separat de software
Trei cadre din arhiva mea: peisaj la Bâlea, oraș în Stockholm și un detaliu de păpădie.
