Spotkania, które naprawdę da się znaleźć: wydanie z osią czasu

Na początku 2026 roku użytkownicy GeekBye mieli problem z historią. Aplikacja nagrywała i analizowała ich spotkania bez zarzutu — a potem wrzucała je do dropdownu. Dropdown jest w porządku przy trzech pozycjach. Przy piętnastym spotkaniu „ta rozmowa kwalifikacyjna z zeszłego wtorku" stawała się ekspedycją archeologiczną przez identycznie wyglądające wiersze. v1.7.3 — 64 commity między połową grudnia a 16 stycznia — to wydanie, w którym spotkania stały się czymś, co naprawdę da się znaleźć.

(Jedna uwaga porządkowa, bo historia gita jest uczciwa nawet wtedy, gdy numery wersji nie są: tag wydania v1.7.2 nie istnieje. Wersja została podbita, ale następnym tagiem, który wyszedł, był v1.7.3, więc windowsowe poprawki z ery v1.7.2 pojechały w tym wydaniu.)

Od dropdownu do osi czasu

Flagowa zmiana to jeden pull request: 12 plików, +640 linii, w większości nowy 381-liniowy komponent MeetingsTimeline. Dropdown stał się przewijalną osią czasu kart spotkań, pogrupowanych w cztery kubełki — Today, Yesterday, This Week, Older (Dzisiaj, Wczoraj, W tym tygodniu, Starsze) — z datami renderowanymi tak, jak powiedziałby je człowiek: Today, 2:30 PM, Yesterday, 2:30 PM, Mon, 2:30 PM dla bieżącego tygodnia i Jan 5, 2:30 PM dalej. Cmd/Ctrl+K ustawia fokus na polu wyszukiwania filtrującym po tytule. Widok szczegółów spotkania stał się prawdziwą stroną nawigacji, więc przyciski wstecz i dalej w navbarze wreszcie coś znaczą, a breadcrumb przestał pokazywać „Meetings / Meeting" i zaczął pokazywać „Meetings / Interview with John" (przycięte wielokropkiem, bo zawsze znajdzie się ktoś, kto nazwie spotkanie jak powieść).

Razem z tym wyszły dwa drobne usprawnienia jakości życia: przycisk usuwania wewnątrz widoku spotkania (który po skasowaniu odsyła cię z powrotem na oś czasu, zamiast zostawiać na martwej stronie) oraz auto-nawigacja — gdy sesja słuchania kończy się z faktyczną treścią transkryptu, dashboard otwiera się od razu na stronie szczegółów tego spotkania. Kończysz rozmowę, widzisz spotkanie. Sesje kończące się pusto są po cichu usuwane, zamiast zaśmiecać oś czasu.

Wyścig, który tworzysz, ulepszając nawigację

A oto część, której changelog ci nie powie. Stara lista spotkań miała nawyk: przy każdym załadowaniu auto-wybierała najnowszą sesję. Nieszkodliwe, dopóki lista była dropdownem, którego rzadko dotykałeś. Zabójcze w chwili, gdy spotkania stały się stroną, po której nawigujesz: klikasz spotkanie #5, w tle kończy się refetch i lista usłużnie wybiera najnowsze spotkanie — nadpisując wybór, którego dokonałeś dwie sekundy temu. Poprawką nie był sprytniejszy guard; było nią całkowite usunięcie auto-selekcji. Każda lista, która wybiera coś w imieniu użytkownika, w końcu zacznie z nim walczyć.

Usunięcie jej odsłoniło drugi wyścig. Auto-nawigacja skacze do spotkania w chwili, gdy jego sesja się kończy — co może nastąpić, zanim ta sesja skończy zapis do lokalnej bazy SQLite. Nawiguj zbyt szybko, a trafisz do spotkania, które jeszcze nie istnieje. Wydana poprawka to 500-milisekundowe opóźnienie przed załadowaniem sesji przy wejściu w widok szczegółów, a handler nawigacji nosi własne asekuracje — czekanie na did-finish-load okna plus 100ms, jeśli dashboard właśnie został utworzony, 50ms, jeśli był już otwarty. Nasze odczytanie: nawigacja po zakończeniu sesji przecina trzy domeny czasowe — zapis do bazy, załadowanie okna i montowanie Reacta — i każda dostała własne małe opóźnienie. Działa, i powiemy wprost: stos magicznych liczb to uczciwy dług, nie zwycięstwo.

Screenshot starszy niż jego własne spotkanie

W tym wydaniu umarło jeszcze jedno założenie: „screenshoty należą do sesji wtedy i tylko wtedy, gdy zostały zrobione w jej trakcie". Idealnie logiczne. Błędne. Prawdziwi użytkownicy wciskają Cmd+H na ogłoszeniu o pracę, agendzie, kodzie, o którym zaraz będą rozmawiać — zanim nacisną Start. Zakładka Report dopasowywała screenshoty do zakresu czasowego sesji ściśle, więc te przygotowawcze screenshoty znikały z raportu, dla którego zostały zrobione. Poprawka poszerzyła okno dopasowania o 60 sekund przed startem sesji. (Sama maszyneria zakresów czasowych jest starsza — wyszła po cichu w v1.6.15; wkładem v1.7.3 jest nauczenie jej, że spotkania zaczynają się odrobinę przed tym, jak się zaczynają.)

Pięć poprawek w dwadzieścia osiem minut

Historia z pola bitwy tego wydania w ogóle nie siedzi w osi czasu — siedzi w windowsowym overlayu onboardingu i jest to podręcznikowy łańcuch „napraw poprawkę": pięć commitów między 10:50 a 11:18 tego samego ranka.

Główne okno GeekBye używa przepuszczania myszy — hooka, który przełącza Electronowe setIgnoreMouseEvents przy każdym ruchu myszy, żeby kliknięcia przechodziły przez przezroczyste obszary. Podczas onboardingu na Windowsie ten hook walczył z overlayem samouczka i na kroku, w którym pojawia się okno dashboardu, aplikacja zamarzała. Poprawka numer jeden: niech hook nie robi nic, dopóki onboarding jest aktywny. Pokój przez rozbrojenie.

Tyle że teraz przyciski onboardingu nie reagowały, bo forwardowanie zdarzeń wysyłało kliknięcia do okna dashboardu pod overlayem. Poprawki dwa i trzy dłubały przy forward: false per kreator. Potem przyszedł commit, który znalazł faktyczną przyczynę źródłową: gdy otwiera się okno dashboardu, jego handler przeciągania resetuje główne okno do trybu klikania na wskroś — a pierwsza poprawka uczyniła hook przepuszczania pasywnym, co oznaczało, że nie zostało nic, co mogłoby skorygować tę ingerencję. Prawdziwa poprawka odwróciła strategię: hook teraz aktywnie re-asertuje setIgnoreMouseEvents(false) przy każdym ruchu myszy podczas onboardingu, właśnie dlatego, że zewnętrzny kod może go zresetować w dowolnym momencie. Skasowała też 75 linii wcześniejszych obejść robionych per kreator.

I nawet wtedy pojawił się piąty commit, bo wygranie wojny o input nie jest wygraniem wojny o z-order: overlay i dashboard siedziały na tym samym poziomie always-on-top, a Windows podnosi to okno, które dostaje fokus. Overlay przeniósł się na wyższy poziom okna i ponownie wynosi się na wierzch z opóźnieniem po pojawieniu się dashboardu. Ten łuk warto zapamiętać: pasywna poprawka, która rozbraja twojego jedynego obrońcę, jest gorsza niż pierwotna walka.

Trzy rzeczy, których nauczyło nas to wydanie

1. Ulepszenia nawigacji wyciągają na wierzch bugi stanu. Wyścig auto-selekcji istniał przed v1.7.3; dropdown po prostu nigdy nie pozwalał go poczuć. W chwili, gdy spotkania stały się stroną, po której świadomie nawigujesz, każdy kawałek kodu wybierający rzeczy za ciebie stał się bugiem.
2. Granice czasowe wokół intencji użytkownika potrzebują luzu. Sesje, nagrania, raporty — użytkownicy działają odrobinę przed i odrobinę po oficjalnym oknie maszyny. 60-sekundowy bufor na screenshoty to jedna linia, która odzwierciedla, jak ludzie naprawdę się zachowują.
3. Nigdy nie czyń swojego kodu korygującego pasywnym. Windowsowe zamrożenie wymagało pięciu poprawek, bo poprawka numer jeden wyłączyła jedyny mechanizm, który mógł przeciwdziałać zewnętrznej ingerencji. Jeśli inny kod może w dowolnej chwili złamać twój inwariant, twoim zadaniem jest re-asertować go bez przerwy, a nie stać z boku.

Po poprzedni rozdział historii v1 — budowanie dwóch zbrandowanych aplikacji z tej jednej bazy kodu — zobacz jedna baza kodu, dwie aplikacje: jak robić white-label bez forkowania (v1.7.1); a po cały łuk — anatomię dostarczania oprogramowania do perfekcji.