[ASK DevForum] Ce ati realizat saptamana asta

  • upgrade vuejs2 to vuejs3
  • finish SAP integration
  • cut my hair
  • make an LLC in usa :smiley:
1 Like

Este mare la inceput(cand inca nu ai deprins ce si cum) sau atunci cand aplicatia are durata de viata scurta. Daca aplicatia are durata de viata mai mare de 1 an si in toata perioada ai nevoie sa o mentii/upgradezi atunci overhead-ul devine negativ.

1 Like

Io-te ca aspectul asta (durata de viata) nu l-am luat in considerare cand ma gandeam la TDD. Bun punct.
Ma gandeam initial doar la complexitatea aplicatiei.

Ca sa-mi raspund partial singur am bagat un quick review la unit testing cu python. Pytest pare cel mai potrivit. E faina si integrarea cu vscode. Benchmark-ul iar e smecherie.
O sa implementez unit tests la o mini aplicatie si vad care-i treaba.

@patkoscsaba - cum verifici if-urile din aplicatie cu unit testing? Integrezi cumva codul de test in codul sursa?

Branch Testing.

Aha. Cred ca am inteles. Deci testezi ptr. toate combinatiile (si valorile) de if-uri (branches) din aplicatie, ca sa ai cat mai mult coverage de cod sursa.
Thanks man, io-te ca omul invata ceva nou in fiecare zi! :slight_smile:

Eu programez de cateori am sansa folosing TDD (test driven development). Si fac asta de vreo 10 ani. Asa ca pentru mine nici nu este de conceput sa fac cod fara teste. Iar daca se poate fac testele inainte de cod.
Desigur, cand sunt doar simple “framework stuff” care fac magie si nimica logica de la mine, fac doar niste teste de system.

Am folosit TDD ptr. un proiect mic (2 zile) in python folosind pytest.
TDD insemnand:

  • scris testele prima data si asigurandu-ma ca dau fail (pytest.fail())
  • scris cod care sa faca testele sa treaca

Ce avantaje am observat folosind TDD:

  • Ptr. mine cel mai important e ca ma obliga sa scriu un api mult mai clar si curat. Daca ai o functie care face prea multe n-ai cum s-o testezi. Deci incerci sa limitezi fiecare functie la a scrie un lucru.
  • structura overall a proiectului e din nou mai curata. Inainte de TDD imi scriam functiile “din mers”, improvizand pe parcurs. Asta a dus la functii care faceau prea multe, imbarligate, rezultand intr-o structura “murdara”.
  • ce viata misto fara exploratory testing (testarea manuala facuta fara TDD). De obicei adaugam la sfarsitul fisierului py cod care sa testeze functii si le comentam afterwards. Asta insemna zero repetabilitate daca as fi vrut sa testez dupa o vreme (cand as fi uitat).
  • bai, overall nu cred ca a facut procesul de scris cod mai indelungat. Testele se scriu foarte rapid, ai o functie cu niste assert-uri basically. Metodologia in sine iarasi nu aduce overhead - in loc sa rulezi aplicatia (app.py) ptr. exploratory testing rulezi test runner-ul (pytest -v -s).
  • Dispare grija ca poate introduci un bug fara sa vrei cand modifici codul de productie. De obicei rulam testele in creier cand modificam codul (ruland scenarii folosind memorii despre aplicatie si codul sursa scris). Asa cum stim cu totii creierul nu-i exact cel mai reliable cand vine vb de memorie si tinut multe chestii in minte deodata (peste 7-8). Si acum ruleze testele in creier dar am o plasa de salvare cu TDD-ul.
  • Poate mi se pare dar parca am scris si mai putin cod ptr. aceleasi functionalitati. Overall e putin cod care face cat trebuie. Ma gandesc ca inainte de TDD as fi efectuat anumite teste direct in cod sau early optimization.

TLDR: cel mai bun feature al TDD-ului IMO e ca scrii cod si API mai curat si usor de intretinut. Nici cu feature-ul secundar nu mi-e rusine (teste automate si disparitia ingrijorarii ca ai introdus un bug fara sa vrei).

Dacă e prima dată când faci TDD și zici asta înseamnă că ai făcut tu ceva greșit :smiley:

2 Likes

Tin minte cand ma gandeam ca git nu-mi trebuie si o sa faca procesul de scris cod mai complex/lung. Sau cand citeam despre diverse best practices de scris cod si ma gandeam ca o sa-mi faca viata mai grea. Sau cand auzeam despre un limbaj/framework eficient si ma gandeam ca o sa-mi ia mult timp sa-l invat si nu se merita.

Am acum senzatia ca recomandarile si best practices chiar functioneaza SI in cazul meu (si nu doar ptr. altii).

TLDR: trebuie sa mai adopt si alte best practices. :stuck_out_tongue:

  • Am inceput sa lucrez in WSO2
    Prima lucrare
  • A fost sa actualizez datele de la o baza (Informix) la alta baza (SQL Server) zilnic si plasat printr-un proxy. Totul am scris in XML 128 de line de cod. :heart_eyes:

Am reparat câteva laptop-uri şi puţină programare.
Şi am lucrat la proiectul actual olium.ro :smiley:

@cosminpopovici e fain olium.ro :slightly_smiling_face:
nice job :+1:

Totusi, daca imi permiti doua mici sugestii: subtitlul sa fie cu un fontsize mai mare,
si la campul de cautare primul field sa aiba un placeholder text mai specific, in loc de “cauta dupa” (ex: cauta dupa produs). Iar opacitatea textului din placeholder sa fie mai mica, sau culoarea sa ofere un contrast mai mare.

Functia de Search e f. importanta, asa ca pe mobil, ar fi mai indicat sa pui cele 3 campuri in coloana, unele sub altele :wink:

PS: eu am creat canalul de discord pentru canalul personal de youtube - https://discord.gg/MXpp9eh

1 Like

Am zis sa iau vreo 2 ore sa citesc man-ul comenzii find. Am inceput de pe la vreo 2pm. Acum e 1am si inca sunt la capitolul exemple (ce-i drept e ultimul capitol si am luat si notite la greu). :stuck_out_tongue:
Dar io-te ca acum n-o sa fac prostia find / -delete -name "something*" - ceea ce sa recunoastem e foarte usor de facut (find executa de la stanga la dreapta in afara de comenzi si optiuni globale, -delete fiind una pozitionala).

Pe langa multe alte chestii misto cea mai tare mi se pare functia de ‘list’. Adica daca grupezi o serie de comenzi cu , gen find / \( -name "x" -fprint mylog.txt \), \( -name "y" -fprint mylog2.txt \) - se traverseaza filesystem hierarchy o singura dat. Poti sa ai si zece teste si actiuni. Superb. :slight_smile:

Am realizat că pot avea conflicte dacă folosesc Composer în mai multe plugin-uri de WP.

Am Firebase într-un plugin, am altceva în alt plugin, ambele folosesc Guzzle. Versiuni diferite de Guzzle.

Am găsit Scoper dar la o primă încercare nu am reușit mare lucru.

1 Like

Am avut un code review la un feature din aplicatie si am aplicat ce am primit. Am deschis un CR pentru update.

Am inceput un nou proiect, pentru ca l-am terminat pe ala in C#. C++. Deocamdata UIul e cu… ncurses, menu, forms, dialogs. Mod terminal. In viitor va avea mai multe interfete (inclusiv web), dar asta e prima cerinta.

Un backend rest API pentru un Blog finalizat cu success
Prima parte din front end cu Angular 10 si Material in curs de finalizare.
Am un trello dashboard cu goals in programming outside of work si tot preiau de acolo cate ceva
Arata a ceva de genul :slight_smile:

4 Likes

Imi place cum arata :slight_smile:
Felicitari!

2 Likes

Si pentru ca este un topic nemuritor :grin:

  • am mai finalizat vreo 3 feature-uri in aplicatie
  • mi-am zugravit camera.
  • m-am reapucat de sala si am inceput sa dau jos din kilogramele acumulate
  • mai ajut din cand in cand un fost coleg de munca cu ceva php si js si incerc sa il convertesc la un ide sau macar VSCode
3 Likes