[vmchecker-dev] Inca o chestie nasoala la vmchecker

[Stefan Bucur]

2009/1/29 Alexandru Moșoi <brtzsnr at gmail.com>:
> În data de 29 ianuarie 2009, 13:23, Stefan Bucur
> <stefan.bucur at gmail.com> a scris:
>> Fara suparare, dar in momentul in care ajungeti sa lucrati cu fisiere
>> cu numele astea, cred ca aveti o problema fundamentala de design :P
>> You should look at the big picture, not the details...
>
> hmm... cam imposibil fara suparare... :P
> (poate reusesc sa-i raspund si lui Lucian).

Chill :) Life is beautiful, get some weed :P

>
> de ce crezi ca e o problema? e cel mult un inconvenient. avantajul
> este usurinta cu care poti sa localizezi sursele prin vmchecker si ca
> nu trebuie sa faci tot felul de operatii pe nume doar ca sa se
> potriveasca alfabetului [_0-9a-zA-Z].

Well, eu ma intrebam de ce trebuie distribuita informatia in fisiere
separate, cand ar fi putut fi stocata intr-unul singur si in care nu
mai aveai nici o restrictie de formatare :) Why expose the complexity?
Mai mult, puteai sa scrii un tool de acces la el, sau chiar sa
folosesti direct o baza de date SQLite in loc sa reproiectezi o
structura de stocare. Iar ce spun eu cred ca adera cu multe din
principiile din link-ul pe care l-ai dat tu acum :P

Tot legat de asta, am impresia ca vmchecker-ul a fost conceput pentru
a fi utilizat din shell, si lucrand direct cu componentele lui. Which
is not very popular for everyone si in plus poti gresi urat de tot la
utilizare (de exemplu eu am sters din greseala niste chestii - bine ca
aveam back-up). (Observ ca notele de la T3 si T5 la CPL nu au fost
trecute si in vmchecker - care ar fi unul din motive? :P)

Cam asta ar fi feedback-ul meu dupa cateva zile de utilizare vmchecker. :)

Numai bine,
Stefan "don't reinvent the wheel" Bucur

>
> ps. Special cases aren't special enough to break the rules. [0]
> [0] http://www.python.org/dev/peps/pep-0020/

Foarte fain link-ul :)