Jak powstał mój METAR (cz. 1): pomysł i stack

8.10.2026 · 2 min czytania

To pierwszy wpis z serii o tym, jak krok po kroku zbudowałem METAR — moją aplikację do podglądu pogody lotniczej. Zacznę od początku: skąd w ogóle pomysł i z jakich „klocków” go złożyłem. Kod i konkrety przyjdą w kolejnych częściach.

Skąd pomysł#

Pracuję w miejscu, gdzie pogoda ma znaczenie. Kiepskie warunki pogodowe, takie jak burze, śnieżyce czy chociażby z pozoru niewinne jesienne mgły, mają ogromny wpływ na operacje lotnicze.Dotychczas korzystałem z zewnętrznych narzędzi, ale chciałem mieć własny, czytelny, spersonalizowany podgląd aktualnej pogody i prognozy na lotnisku — a przy okazji nauczyć się front-endu na czymś realnym, a nie kolejnej to-do liście.

Czym jest METAR (i TAF)#

Dla osób spoza branży w dwóch zdaniach:

Oba, w wersji surowej zapisane są gęstymi skrótami, np. BKN, VFR, TEMPO. Dla fachowca czytelne od ręki, dla reszty — szyfr. (W jednym z kolejnych wpisów pokażę, jak zamieniłem te skróty na ludzki język.)

Dlaczego własna apka, skoro są gotowe serwisy?#

Trzy powody:

  1. Nauka — chciałem zrozumieć, jak działa pobieranie danych z API, typowanie, komponenty.
  2. Czytelność — własny widok, dokładnie taki, jaki mi pasuje.
  3. Jednostki metryczne — wolę odległości podawane w metrach i prędkości w m/s zamiast stóp i węzłów, więc apka od razu to przelicza.

Stack — i dlaczego taki#

Co dalej#

W części 2 zajmiemy się pierwszym prawdziwym wyzwaniem: jak schować klucz API, żeby nie wyciekł do świata. To był jeden z ważniejszych (i najbardziej pouczających) momentów całego projektu.

Aplikację na żywo i kod podlinkuję na końcu serii — a jak nie możesz się doczekać, zajrzyj do mojego GitHuba. 😉

Więcej z tej serii

  1. 1.Jak powstał mój METAR (cz. 1): pomysł i stack
  2. 2.Jak powstał Avia Weather (cz. 2): skąd brać dane i jak ukryć klucz API
  3. 3.Jak powstał Avia Weather (cz. 3): jak rozszyfrować METAR na ludzki język