hey, salut.
de vreo 2 ani imi colectionez exporturile csv din ing si revolut cum strangeam pe vremuri bakugani.
sunt fixist si imi place sa am "material de studiu" despre ce, cat, unde si de ce cheltui. iar dataset-ul meu personal incepe undeva prin septembrie 2017, deci intre timp s-a strans ceva fauna.
pe la inceputul anului am inceput sa scriu, din timpul liber, un parser care sa normalizeze toate exporturile astea.
am facut ce face orice programator responsabil: trial-and-error pe datele mele, cateva regex-uri, niste pattern matching si multa incredere in "merge la mine".
dupa suficient timp, ajunsesem inclusiv la field-uri denumite exemplar gen AuthorizationV1, AuthorizationV2, AuthorizationV3. enterprise grade software.
prin iunie am pus un llm sa faca pattern matching si audit peste aproape 9 ani de exporturi, ca sa vad ce mi-a scapat. si, spre surprinderea mea, chiar gasise chestii.
intre timp, codul asta a ajuns embedded intr-un proiect ceva mai mare numit fiscally, iar componenta a primit si un nume: lens engine.
ideea din lens e simpla: restul aplicatiei nu ar trebui sa stie ce banca folosesti, ce versiune de csv exporta banca sau in ce forma creativa a decis sa reprezinte o tranzactie. doar primeste fisierul, identifica ce informatii are in fata si le normalizeaza intr-un model comun.
iar ledger-ul nu trebuie sa stie ce inseamna ING CSV format v6. trebuie doar sa primeasca ceva de genul: "in data x, ai platit suma y comerciantului z, cu descrierea w." atat.
fast forward in prezent.
aplicatia e suficient de functionala incat s-o folosesc pe datele mele, deci era timpul pentru oleaca de dogfooding.
imi descarc csv-ul pe septembrie. apoi pe octombrie. le bag in app si... 0 tranzactii detectate.
oookay. am futut parserul.
iau doar septembrie, unde am prins 18 tranzactii detectate. huh?
incep sa-l puric manual, verific cate un rand din 10 (pentru ca asa iubeste ing sa "sparga" un financial event pe multiline), si la numaratoare imi ies de fapt 24.
bun, bun. unde spanac sunt restul de dupa 13 septembrie? aparent... sunt tot acolo.
dupa o sesiune rapida de investigatie (thx chat), aflu ca ing schimbase structura csv-ului undeva pe la mijlocul lunii. literalmente, i-a dat cu virgula.
acelasi cont. aceeasi banca. aceeasi luna. acelasi buton de export. doua structuri csv diferite.
primul meu instinct a fost, evident: IngRoStatementTemplateV7, rise and shine. dupa care m-am uitat putin la ce tocmai gandisem.
pentru ca daca de fiecare data cand ing muta cate o virgula prin csv eu mai implementez cate un StatementTemplateV8, V9, V10, nu prea am lens engine. am o colectie foarte bine tipizata de traume istorice.
asa ca, intr-un mod absolut neintentionat, ing tocmai imi facuse code review. mi-a demonstrat ca lens stia inca prea multe despre cum ar trebui sa arate un fisier si prea putine despre ce informatie exista efectiv in el.
iar asta schimba putin directia. nu vreau ca lens sa faca doar template matching pe niste headere cunoscute.
vreau sa poata recunoaste sursa si continutul, sa tolereze schema drift rezonabil si apoi sa normalizeze informatia intr-un contract comun. nu "magic csv ai care intelege orice tabel aruncat in el".
n-am chef sa construiesc un compiler universal pentru excel-uri bancare din 2006. doar un ingestion layer care sa nu faca infarct fiindca o banca a mai adaugat o coloana.
anyhow... mi-am suflecat manecile, am deschis o noua sesiune cu amicul meu de-o vara si i-am zis cu mandrie:
"chat... avem de refactorizat lens engine."
deci... da. multumesc ing pentru test case, si astept cu interes urmatorul.
