Słownik

Jak każda branża profesjonalna, tak i IT ma swoje własne nazwy. W polsce zazwyczaj jest to mieszanka polskiego, angielskiego oraz slangu. Dodatkowo, w każdym projekcie pojawiają się skróty, przyspieszające komunikacje. Dlatego dla osób dołączających do naszego projektu przygotowaliśmy bardzo krótki słownik pojęć, którymi posługujemy się w naszym projekcie.

EC = Epomis Cloud - nazwa projektu

EM = Epomis Mobile - nazwa projektu

PoC = Proof of Concept - "dowód" najczęściej w postaci kodu, że Twój pomysł działa. O tym dowodzie raczej myśl jak o dowodzie matematycznym niż jak o dowodzie w sądzie.

MVP = Minimal Valuable Product = v1 - najmniejsza możliwa (najbardziej okrojona) aplikacja która jednak robi cokolwiek sensownego i przydatnego.

CS = ConnectionService - wewnątrz Epomisa wykształcił się nam na przestrzeni lat moduł do wykonywania i przetwarzania zapytań sieciowych. Pod spodem używa wielu różnych klientów (w tym od Googla i Apache'a), sam pozwala na przetwarzanie tych zapytań asynchroniczne na reaktywnym strumieniu oraz wystawia interfejs uniezależniający nas od jakiejkolwiek konkretnej implementacji klientów.

HAR = HttpARchive - JSON opisujący komunikacje przeglądarki (Chroma lub Firefoxa głównie) z jakąś stroną. HAR nie jest naszym wynalazkiem, my go tylko używamy jako wtyczka do CS by użyć przeglądarki do opisania zapytań zamiast robić to ręcznie.

Harlina - nazywa projektu. Nie ma absolutnie nic wspólnego z HARem.

GL = GitLab - bardzo rozbudowane oprogramowanie, między innymi do hostowania naszego kodu na serwerze.

BB = BitBucket - alternatywa dla GL, tylko hostowana nie u nas na serwerze tylko w chmurze (chociaż GitLab też ma wersje hostowaną w chmurze). Kiedyś używaliśmy BitBucketa ale się przenieśliśmy na GitLaba. 100% kodu który był zabraliśmy ze sobą, więc jeśli w tasku jest napisane, że coś jest na BB to jest też w GL.

GH = GitHub - alternatywa BB

SQ = SonarQube - narzędzie do statycznej analizy kodu

CI/CD = Continous Integration/Continous Deployment - podejście do tworzenia oprogramowania polegające na tym, że każda zmiana jest sprawdzana na zgodność z poprzednią wersją, w szczególności czy wszystko nadal działa. Jeśli wszystko jest ok, to poprzednio zainstalowana wersja powinna zostać zastąpiona przez nowszą.

PR = MR = Merge Request - wyklikana z Gitlaba (w naszym przypadku) prośba o włączenie Twojego kodu do głównego brancha. Prawie każdy task do ukończenia wymaga MRa.