Po godzinach w IT rekordy siłowe

Seria: Po godzinach w IT / rekordy siłowe / część 1

Od tabelki w Excelu do strony z rekordami

Mały projekt, który zaczął się od tabeli rekordów dla znajomych, a skończył jako prosta strona z wynikami edytowanymi w arkuszu.

Po godzinach w IT

To jest pierwszy wpis z serii Po godzinach w IT — o małych projektach, które robiłem po pracy, często z ciekawości, czasem z potrzeby, a najczęściej z połączenia jednego i drugiego.

Nie będę pisał o wielkich systemach ani rozwiązaniach projektowanych przez duże zespoły. Tylko o rzeczach, które zaczynają się od prostego pytania: „czy da się to zrobić trochę wygodniej?”. Dla mnie właśnie takie projekty są jednym z najlepszych sposobów nauki. Mogę sprawdzić nowe podejście, popełnić kilka błędów, poprawić je i na końcu mieć coś, co naprawdę działa.

Na pierwszy ogień idą rekordy siłowe.

Pomysł był prosty

Razem ze znajomymi chcieliśmy mieć miejsce, w którym szybko możemy pokazać nasze rekordy innym osobom. Bez wysyłania arkusza, bez tłumaczenia, kto ma do niego dostęp, i bez ryzyka, że ktoś przypadkiem zmieni wartości. Zwykła tabela była dobrym początkiem, ale docelowo lepiej sprawdza się mała strona: każdy może ją otworzyć, wyniki są czytelne, a edycja danych zostaje po naszej stronie.

Na początku do takiej rzeczy wystarcza zwykły arkusz. Kilka osób, kilka ćwiczeń, wartości w kilogramach i gotowe. Mówię „Excel”, bo dla wielu osób tak po prostu nazywa się każda tabelka z danymi, ale w praktyce u mnie tym arkuszem był Google Sheets.

Arkusz ma jedną dużą zaletę: jest szybki. Nie trzeba projektować aplikacji, logowania, bazy danych ani panelu administracyjnego. Wpisujesz wynik i po sprawie.

Kiedy arkusz zaczyna przeszkadzać

Problem zaczyna się wtedy, kiedy chcesz te dane pokazać dalej, ale niekoniecznie chcesz udostępniać sam arkusz. Dochodzi zarządzanie dostępem, pilnowanie uprawnień, ryzyko przypadkowej edycji i ręczne aktualizowanie wszystkiego w kilku miejscach. Przy małej tabeli da się z tym żyć, ale po pewnym czasie zaczyna to przeszkadzać.

Można oczywiście przepisać wyniki ręcznie na stronę. I na początku dokładnie tak zrobiłem. Powstała prosta tabela w HTML-u: osoby w wierszach, ćwiczenia w kolumnach, a w komórkach wyniki. Działało. Było czytelne. Przy kilku rekordach nie było z tym żadnego problemu.

Ale ręczna edycja strony szybko robi się mało wygodna. Każda zmiana wyniku oznacza poprawianie pliku strony, wrzucanie nowej wersji i sprawdzanie, czy niczego przy okazji nie zepsułem. Przy jednej zmianie to drobiazg. Przy kolejnych zaczyna przeszkadzać.

Chciałem więc zostawić prostotę arkusza, ale nie edytować już strony ręcznie.

Mały przepływ danych zamiast dużej aplikacji

Pomysł na przepływ danych był taki:

  • arkusz zostaje miejscem, w którym wygodnie dodaje się rekordy,
  • prosty formularz w arkuszu pozwala wybrać osobę, datę i ćwiczenia,
  • dane są wysyłane do małego pośrednika technicznego, czyli Cloudflare Workera,
  • ten pośrednik zapisuje aktualne rekordy i historię zmian,
  • strona pobiera dane i sama wyświetla aktualną tabelę.

Efekt końcowy nadal wygląda prosto: tabela rekordów, wynik i data. Pod spodem dzieje się jednak trochę więcej niż w zwykłym HTML-u.

Tabela rekordów siłowych z wynikami i datami
Prosta tabela rekordów — wyniki są edytowane w arkuszu i automatycznie pokazują się na stronie.

Bez własnego serwera i praktycznie bez kosztów

Najważniejsze jest to, że nie trzeba od razu budować dużej aplikacji. Ten projekt można zrobić małymi krokami, bez stawiania własnego serwera i praktycznie bez kosztów. Wystarczą narzędzia, które dobrze nadają się do takich małych automatyzacji: Google Sheets, Google Apps Script, Cloudflare Workers i Cloudflare D1.

To samo podejście można później przenieść na inne rzeczy. Zamiast rekordów siłowych można zrobić tabelę rekordów klubu sportowego, zestawienie wyników testów, ranking zawodników albo prosty panel do aktualizowania danych na stronie.

Co będzie dalej

Dla mnie w takich projektach najważniejsze jest to, że każdy element ma sens. Arkusz nie jest już tylko tabelką. Skrypt nie jest pisany dla samego pisania kodu. Baza danych nie pojawia się dlatego, że „tak trzeba”, tylko dlatego, że chcemy zapisywać dane i historię zmian w bardziej uporządkowany sposób.

W kolejnej części pokazuję, jak wyglądała architektura tego rozwiązania: jak połączyłem arkusz, Apps Script, Workera, D1 i statyczną stronę w jeden prosty przepływ danych.

To wpis z serii Po godzinach w IT. Techniczne teksty planuję publikować głównie w czwartki, a wpisy z serii Z basenu do kodu zostawić na niedziele.

Czytaj dalej w serii

Po godzinach w IT: Rekordy siłowe

  1. Część 1 Od tabelki w Excelu do strony z rekordami
  2. Część 2 Jak działa strona z rekordami: arkusz, Worker, D1 i zwykły HTML
Wróć do listy wpisów