nats.net

Contribution documentation

Authors

• pzajaczkowski
• fdrazba
• bciereszynski

Attempt 2 - NATS

NATS is a lightweight and high-performance messaging system designed for asynchronous communication among different software components, with modern clustering, security and persistence streaming support out of the box, in a single compact binary with no dependencies, available for any modern platform, enabling a vast variety of deployment options from edge, IoT, Kubernetes to bare-metal.

What has been done:

• Issue - Add force reconnect method

  • Reading project documentation
  • Setting up local environment
  • Getting familiar with code base and used conventions
  • Trying to understand problem and NATS infrastructure
  • First code changes
  • Asking for details of some expected behaviour of the method to implement
  • Created pull request with solution
  • 
  • Pull request accepted and changes merged to main 🎉
  • 

• Issue - Implement Lame Duck Mode Event Handler

  • Research about Lame Duck Mode topic
  • Looking how does LDM looks in code
  • Brainstorm about best solution and its architecture
  • Session of pair programming with Filip and Bartosz
  • First solution with trigger method
  • Second solution with setter
  • Decision to go with second solution
  • Created pull request
  • 
  • Fixed 2 problems mentioned in PR conversations
  • Ask for help with feature with no public documentation
  • Change test to work with multiple enviroments (i.e. work with windows)
  • Pull Request merged 🎉
  • 

Attempt 1 (Failed) - Nuclear

At first, we planned to contribute to an open-source streaming music player. Unfortunately, due to safety concerns regarding this program and its repository, we decided to contribute to a different project (NATS). Even though we switched our contribution project, we still spent some time on the previous one.

Here is what we have done for Nuclear:

Opis planowanych zadań:

• Projekt zmian w UI
  • Celem jest stworzenie konkretnego projektu dotyczącego wyświetlania CD.
  • Projekt powinien być inspirowany dostarczonymi zrzutami ekranów z innych aplikacji oraz dostosowany do estetyki naszej aplikacji.
• Implementacja adaptera
  • Adapter to klasa odpowiedzialna za przechwytywanie odpowiedzi na zapytania i przekształcanie ich w jednolite dane do wyświetlenia przez GUI.
  • Istnieje już kilka adapterów w kodzie, dlatego zadanie polega na dostosowaniu istniejących klas lub ewentualnym dodaniu nowej klasy na podstawie istniejącego kodu.
• Wprowadzenie zmian do kodu obsługującego UI
  • Na podstawie projektu oraz danych dostarczonych przez adapter należy wprowadzić zmiany w klasie odpowiedzialnej za wyświetlanie tablicy utworów.
  • Zmiany te powinny być stosunkowo proste, ale wymagają wcześniejszego zakończenia implementacji adaptera lub ustalenia interfejsu komunikacyjnego.
  • Zmiany będą skupione na klasach GridTrackTable oraz GridTrackTableRow.
• Utworzenie testów jednostkowych
  • Zwiększenie pokrycia testami jest wymogiem zgodnym z naszymi zasadami wkładu: pokrycie powinno przynajmniej pozostać na tym samym poziomie, aby PR mógł zostać scalony.
  • Przykłady testów jednostkowych są dostępne w dokumentacji.
• Dodanie testów UI
  • W repozytorium, obok standardowych testów jednostkowych, znajdują się testy graficzne zwane testami snapshot.
  • Przykłady testów snapshot są dostępne w dokumentacji.
  • Zadanie to obejmuje zrozumienie tych testów oraz dodanie ich w kontekście wprowadzanych zmian, jeżeli będzie to możliwe.

Roadmap

Diagram aktywności

Projekty zmian w UI

• 

• 

• 

This site is open source. Improve this page.