0.11.40 – 0.11.68 — dwadzieścia dziewięć wydań, jeden wpis

Reguła w tym projekcie brzmi: każda zmiana kodu silnika to nowe wydanie, a każde wydanie to wpis w changelogu. Pierwsza połowa działała. Druga stanęła 8 września na 0.11.39 i nie ruszyła przez trzy dni, w czasie których wyszło dwadzieścia dziewięć kolejnych wersji.

Można było napisać dwadzieścia dziewięć wpisów wstecz. Byłyby nieuczciwe — pisane po fakcie, z pamięci, każdy udający notatkę z chwili wydania. Ten wpis jest zamiast nich i nie udaje niczego innego, niż jest: nadrobieniem zaległości.

MUR REJESTRACYJNY I KONTA CZYTELNIKÓW (0.11.40 – 0.11.59)

Największy blok i jedyny, który zmienia to, co czytelnik widzi na pierwszym ekranie. Wpis może mieć próg: dalszy ciąg dostają osoby z kontem. Konto jest darmowe, zakłada się je adresem e-mail, a logowanie idzie odnośnikiem z poczty — bez hasła, bo hasła nie ma czego wykraść.

Wokół tego narosło kilkanaście poprawek, z których każda wyszła z jednej konkretnej sytuacji. Zapowiedź pokazuje teraz ułamek tekstu zamiast urywać się w połowie zdania. Zdjęcie za murem gaśnie gradientem i ma przycisk. Powrót po zalogowaniu prowadzi do wpisu, od którego się zaczęło, a nie na stronę główną — najpierw przez adres w odnośniku, potem, gdy okazało się to zawodne, przez adres zapisany przy żetonie po stronie serwera.

Osobno stanęła zgoda na wysyłkę: pole, przełącznik na stronie konta, znacznik czasu i wersja regulaminu, na którą zgoda została udzielona. Zgoda bez zapisanej wersji dokumentu jest bezużyteczna, gdy dokument się zmieni.

I rzecz, którą trzeba było naprawić dwa razy, bo za pierwszym razem zrobiono ją zbyt płytko: podpinanie dorobku czytelnika do świeżo założonego konta. Pierwsza wersja szła przez identyfikator przeglądarki podany przez klienta. Druga przywiązuje identyfikator do żetonu logowania i wykonuje całą operację po stronie serwera, jednym torem.

BLOKI KODU I LOGÓW (0.11.60 – 0.11.61)

Do 0.11.60 treść wpisu była tablicą napisów, a każdy napis renderował się jako akapit. Wystarczało prozie, dla której silnik powstał. Nie wystarcza tekstom technicznym: fragment kodu wklejony w akapit traci wcięcia, łamie się w losowych miejscach i zlewa z narracją.

Element treści może być teraz obiektem — blokiem kodu, oknem konsoli albo nagłówkiem. Rozszerzenie jest wstecznie zgodne, więc instancje mające w treści same napisy nie zauważyły zmiany. Kolorowanie składni napisano od zera, bez biblioteki: highlight.js to kilkadziesiąt kilobajtów w paczce workera za rozpoznanie napisów, komentarzy, liczb i listy słów kluczowych, a przy okazji cudza paleta kłócąca się z motywem instancji.

Okna konsoli są dwa — czarne dla powłoki uniksowej i granatowe dla PowerShella. Te dwa kolory są wpisane na sztywno, nie wzięte z motywu, i to jest świadome: tak wyglądają te okna u każdego, więc są cytatem z rzeczywistości, a nie decyzją estetyczną instancji.

W 0.11.61 akapity dostały skład justowany z dzieleniem wyrazów. Dzielenie nie jest ozdobą: polski ma długie słowa i justowanie bez przenoszenia rozpycha spacje, robiąc w kolumnie białe rzeki. Poniżej trzydziestu rem justowanie się wyłącza, bo wąska kolumna na telefonie znosi je gorzej niż szeroka.

NAZWY WŁASNE WYPADAJĄ Z SILNIKA (0.11.62)

Najbardziej wstydliwe wydanie z całej serii. W domyślnych napisach silnika stały nazwy własne jednej z instancji — w zdaniu o zgodzie na wysyłkę i w opisie konta podstawowego. Wartości domyślne kompilują się razem z kodem, więc szły do paczki przeglądarki KAŻDEJ instancji, także tych, których nie dotyczyły.

Istniejący strażnik nie miał jak tego złapać: pilnuje, żeby napisy nie stały w komponentach, a słownik napisów jest właśnie miejscem, gdzie stać im wolno. Nowy strażnik działa z dwóch stron. Heurystycznie szuka wyrazu wielką literą w środku zdania — to łapie markę, o której nigdy nie słyszał. Do tego czyta nazwy z konfiguracji wskazanych instancji: markę, autora i domenę. Dopisanie nowej instancji rozszerza ochronę samo, bez edycji skryptu.

PROPAGACJA WYDAŃ (0.11.63, 0.11.68)

Silnik żyje w swoim repozytorium, ale wykonuje się w instancjach. Do tej pory wciągało się go tam ręcznie i regularnie o tym zapominało — dwie instancje stały na 0.11.39, gdy silnik miał 0.11.62, czyli dwadzieścia trzy wydania w tyle.

Tag wydania uruchamia teraz workflow, który dla każdej instancji kopiuje pliki z manifestu, puszcza strażników i otwiera pull request. Nie scala i nie wdraża — nowe wydanie potrafi wymagać uzupełnienia napisów po stronie instancji, a tego nikt za człowieka nie zgadnie. Zielony wynik daje zwykły pull request, czerwony szkic z opisem, czego brakuje.

Pierwsza wersja miała wadę widoczną dopiero przy dużym tempie: nazywała gałąź numerem wydania, więc każde wydanie otwierało nowy komplet pull requestów, a poprzednie wisiały. Pięć wydań w godzinę zostawiło dwadzieścia dwa otwarte pull requesty i zalało skrzynkę powiadomieniami. W 0.11.68 gałąź nazywa się zawsze tak samo, a kolejne wydanie aktualizuje istniejący pull request zamiast zakładać następny.

SKÓRKI INSTANCJI (0.11.64 – 0.11.67)

Instancja może zadeklarować skórkę: `book` albo `dev`. Brak deklaracji oznacza `book`, czyli dokładnie to, co instancje miały dotąd — zmiana jest wstecznie zgodna i cztery starsze serwisy jej nie zauważyły.

`dev` przestawia serwis na stronę techniczną: ciemny nagłówek i stopka na pełną szerokość, znak w monospace, typografia bezszeryfowa, akcent kolorystyczny, wyłączony inicjał. Papier w treści zostaje jasny — ciemne tło przy dłuższym czytaniu męczy, a serwis nadal jest do czytania.

Pułapka warta zapisania: nadpisanie zmiennej `--font-serif` w selektorze skórki NIE działa, bo Tailwind przy `@theme inline` wkleja wartość wprost do wygenerowanych klas. Podmiana kroju musi iść przez samą klasę. Wyszło to na jaw dopiero na zrzucie ekranu — tytuł wpisu został szeryfowy mimo pozornie poprawnej reguły.

Po drodze dwie poprawki z obserwacji. Ikony w nagłówku malują się kolorem tuszu, więc na ciemnym tle znikały; kolor ustawiono raz na kontenerze i resztę robi dziedziczenie, dzięki czemu każdy element dołożony tam w przyszłości dostanie właściwy kolor sam. A strumień znika z nawigacji, dopóki instancja ma jedną serię — dwie zakładki prowadzące w to samo miejsce to szum, nie nawigacja.

CO Z TEGO ZOSTAJE

Trzy z tych wydań naprawiały coś, co wcześniej wypuszczono zbyt płytko: podpinanie dorobku, powrót po zalogowaniu i propagację. Za każdym razem pierwsza wersja działała w warunkach, w jakich ją sprawdzano, i przestawała w tych, w jakich jej używano.

Sam ten wpis jest tego samego rodzaju wnioskiem. Reguła mówiąca „każde wydanie ma changelog" jest dobra, dopóki tempo wydań pozwala ją utrzymać. Przy dziesięciu wydaniach dziennie nie pozwala, a wtedy albo zwalnia się tempo, albo zmienia regułę — nie udaje, że nadal się ją stosuje.