Korepetycje z matematyki prowadzę od lat, a mniej więcej od grudnia 2024 roku chodziła za mną myśl, żeby robić to bardziej profesjonalnie: z własną stroną i kalendarzem, w którym uczeń sam wybiera wolny termin, zamiast umawiać się ze mną w wiadomościach. Na początku 2025 roku przeglądałem gotowe systemy rezerwacji w rodzaju Reservio, ale albo nie pozwalały połączyć lekcji indywidualnych z grupowymi, albo kosztowały więcej, niż byłem gotów zapłacić za coś, co i tak musiałbym naginać do swoich potrzeb. Postanowiłem więc zrobić to sam, choć wcześniej z programowaniem nie miałem nic wspólnego.
Ten wpis jest o pierwszym etapie, czyli o tym, jak z kilku stron i formularza zrobiła się aplikacja, która działa w sieci i przyjmuje rezerwacje. Po drodze popełniłem sporo błędów, a o części z nich dowiedziałem się dopiero wtedy, gdy coś przestało działać.
Pierwsze strony na Flasku
1 września 2025 roku zapisałem pierwszą wersję kodu na GitHubie, czyli w serwisie, który przechowuje kod razem z całą historią zmian. Aplikację napisałem w Pythonie za pomocą Flaska, narzędzia do budowania stron, od razu z myślą o Renderze, firmie, która wynajmuje serwery pod takie aplikacje. We Flasku każda strona ma gotowy szkielet, który serwer uzupełnia danymi, zanim wyśle go do przeglądarki. Na początek wystarczyło mi kilka takich szkieletów (strona główna, oferta, kontakt, kalendarz i formularz rezerwacji), do tego plik opisujący wygląd strony i garść obrazków. Rezerwacje, konta użytkowników, urlopy i ustawienia leżały w zwykłych plikach tekstowych obok kodu, co jeszcze da o sobie znać.
Od samego początku istniał też panel administratora, bo ktoś musiał widzieć rezerwacje, blokować terminy i odpisywać na wiadomości. Cennik nie siedział w bazie danych, tylko w pliku z ustawieniami: najpierw długości lekcji i ceny, później także pakiety z rabatem i raty. Żeby zmienić cenę, poprawiałem plik i wgrywałem całą stronę na serwer od nowa. Wydawało mi się to wtedy rozsądnym uproszczeniem i przez jakiś czas rzeczywiście nim było.
Krótkie podejście do PHP
Pierwszy poważny kłopot nie dotyczył samej aplikacji, tylko tego, gdzie ma działać. Najtańsze serwery, takie, jakie zwykle wynajmuje się pod stronę firmową, są przygotowane pod PHP, czyli inny język programowania, a nie pod Pythona, w którym napisałem Algebrę. Uznałem więc, że skoro serwer jest pod PHP, to przepiszę aplikację pod serwer.
W połowie września przeniosłem całą stronę do nowego projektu w PHP, ale po kilku dniach porzuciłem ten pomysł i wróciłem do Flaska. Zamiast dopasowywać działającą aplikację do serwera, poszukałem serwera, który przyjmie ją taką, jaka jest. Wniosek z tego epizodu jest prosty: wybór serwera to część projektu, a nie formalność na sam koniec.
Render, Koyeb i dwa dni prób
W październiku uporządkowałem wersję na Flasku w nowym projekcie, a 26 października 2025 roku założyłem na GitHubie ten, w którym pracuję do dziś. Od razu leżały w nim instrukcje dla Rendera, który sam buduje i uruchamia aplikację prosto z kodu. Wybrałem darmowy plan i serwer we Frankfurcie, a aplikacja dostała własny adres w sieci.
Zanim jednak wszystko ruszyło, przez dwa dni miotałem się między Renderem a Koyebem, bardzo podobną usługą. Plik, który mówi serwerowi, jak uruchomić aplikację, najpierw dodałem, potem usunąłem, bo Koyeb miał sam rozpoznać Flaska, a na koniec dodałem z powrotem. Musiałem też uzgodnić numer drzwi, za którymi aplikacja czeka, bo serwer, sprawdzając, czy żyje, pukał pod numer 8000, a ona czekała gdzie indziej. Do tego ciasteczka, dzięki którym strona pamięta, kto jest zalogowany, trzeba było na serwerze ustawić inaczej niż na moim komputerze. Ostatecznie wygrał Render i na nim Algebra stoi dziś.
Jeden dzień z nagłówkiem
Osobny rozdział należy się 18 listopada, bo w historii zmian jest z tego dnia ponad dwadzieścia poprawek samego nagłówka, czyli paska z menu na górze strony. Na telefonie menu łamało się w dwa wiersze, przyciski stały schodkowo, a rozwijane menu (ikonka z trzema kreskami) w części dla odwiedzających zachowywało się inaczej niż w panelu administratora. Każda poprawka coś naprawiała i coś innego psuła, aż w końcu cofnąłem wszystkie zmiany do stanu z rana i zacząłem od nowa, tym razem kopiując nagłówek z panelu, który działał dobrze.
Wniosek z tego dnia przydaje się przy każdym projekcie: kiedy poprawki zaczynają się kręcić w kółko, lepiej wrócić do ostatniego dobrego stanu i zrobić jedną przemyślaną zmianę, niż dokładać kolejną łatkę do łatki.
Pierwsze płatności
Jeszcze w październiku podpiąłem do Algebry Stripe'a, firmę obsługującą płatności w internecie, i dopiero na nim zrozumiałem, jak taka płatność w ogóle przebiega. Klient przechodzi na stronę operatora, płaci i wraca na moją stronę, a operator osobno wysyła mojemu serwerowi wiadomość, że pieniądze doszły. Po kilku dniach przeszedłem jednak na HotPay, a w regulaminie strony pojawił się zapis o nowym operatorze płatności. W listopadzie doszły raty i pakiety z rabatem, a przy nich pierwsza poprawka w pliku z cennikiem, bo taki plik nie wybacza nawet jednego źle postawionego przecinka i strona przestaje go wtedy rozumieć.
Gdzie jestem dzisiaj
Trzy miesiące po pierwszej wersji kodu Algebra ma stronę, kalendarz, rezerwacje, panel administratora i płatności. Najwięcej kłopotu sprawia mi teraz baza danych, bo rezerwacje potrafią zniknąć po wgraniu nowej wersji strony. Szukam przyczyny i kiedy ją znajdę, opiszę ją w osobnym wpisie.
Cała seria
Ten wpis otwiera serię o tym, jak powstawała Algebra i Spółka:
- Pierwsza Algebra: Flask, szablony i PHP, z którego szybko zrezygnowałem
- Rezerwacje, które znikały po każdym wdrożeniu
- Algebra od nowa: z szablonów Flaska na Reacta i TypeScript
- Cennik w pliku, Premium i pierwsza bramka płatności
- Zadania, karta wzorów i rysunki, które nie chciały się zgadzać
Jak całość wygląda dzisiaj, opisuję we wpisie Algebra i Spółka od środka.