Najważniejsze zmiany
Zużycie uwzględnia teraz każdą godzinę objętą okresem rozliczeniowym, więc łączna liczba kredytów na stronie Usage & Limits obejmuje okres od jego pierwszej sekundy. Organizacje zyskały dopracowanie, którego brakowało w zeszłym tygodniu: dodana osoba otrzymuje powiadomienie, podobnie jak właściciel opłacający plan, a selektor ról w końcu wyjaśnia uprawnienia. Przejrzeliśmy też Dashboard i przepisaliśmy komunikaty, które wcześniej były tworzone z myślą o nas, a nie o Was.
Co nowego
Każda godzina okresu ma znaczenie
Twój okres rozliczeniowy zaczyna się dokładnie w sekundzie rejestracji. Zużycie mierzone jest w stałych przedziałach. Te dwa elementy rzadko się pokrywają, więc obliczenia mapujące jeden na drugi muszą być precyzyjne na krawędziach.
Teraz tak jest. Okres dzielony jest na pełne przedziały o najwyższej dostępnej rozdzielczości dla każdej części, bez dzielenia i podwójnego zliczania. Wszystkie trzy miejsca odczytujące zużycie korzystają z tej samej implementacji, co stanowi właściwą poprawkę. Trzy niezależne kopie tych samych obliczeń to prosta droga do błędu w jednej z nich.
Co zauważysz: każda liczba w sekcji Usage & Limits jest nieco wyższa niż w zeszłym tygodniu. Ten sam ruch, pełniejsze zliczanie. Nikt nie przekroczy limitu planu z powodu tej zmiany. Ta sama logika kontroluje limity, więc miało to znaczenie w obie strony.
Koniec z cichym dołączaniem do organizacji
Organizacje pojawiły się w zeszłym tygodniu, umożliwiając dodanie współpracownika, przypisanie mu roli i udostępnienie kluczy opłacanych przez firmę. Brakowało jednak automatycznego powiadomienia. Wskazówka pod formularzem sugerowała, aby poinformować o tym samodzielnie.
Teraz wysyłane są dwa maile. Dodana osoba otrzymuje wiadomość z nazwą organizacji, informacją o tym, kto ją dodał, zakresem uprawnień roli oraz opcją opuszczenia organizacji, jeśli się tego nie spodziewała. Właściciel otrzymuje powiadomienie, gdy ktoś dołącza, ponieważ klucze organizacji obciążają jego plan, a kolejny użytkownik zużywający kredyty to kwestia kosztów, a nie uprzejmości. Żaden mail nie trafia do osoby wykonującej akcję. Nie potrzebujesz potwierdzenia własnych działań.
Powiadomienie właściciela działa w obu przypadkach: przy bezpośrednim dodaniu oraz po przyjęciu zaproszenia przy pierwszym logowaniu, gdy użytkownik dołącza samodzielnie.
Role również mają teraz jasny opis. Tekst pod selektorem zmienia się wraz z wyborem, a kolumna Role zawiera tooltip opisujący wszystkie trzy role, w tym właściciela. Wybór między "Member" a "Admin" bez znajomości różnic prowadzi zwykle do domyślnego nadawania uprawnień administratora.
Dodawanie współpracownika w jednym kroku
Wpisz adres email i kliknij Add. Jeśli użytkownik korzysta już z FourA, dołącza od razu. Jeśli nie, wysyłamy zaproszenie mailowe i staje się członkiem w momencie pierwszego logowania. Ten sam przycisk, to samo potwierdzenie, ten sam wynik w obu przypadkach, a strona opisuje oba scenariusze w jednym zdaniu, zamiast wskazywać konkretny wariant dla wpisanego adresu.
To drugie okno dialogowe zniknęło, podobnie jak odpowiedź, która informowała, czy dany adres ma już tutaj konto. To, czy dany adres e-mail jest u nas zarejestrowany, nie jest pytaniem, na które odpowiadamy.
Dashboard przestał pisać do logu
"Failed to fetch organizations" to komunikat dla nas. Wyświetlał się jednak użytkownikom.
Trzydzieści pięć takich komunikatów zamieniono na zrozumiałe zdania, na podstawie których człowiek może podjąć działanie, takie jak "We couldn't load your organizations. Try again in a moment." Naturalne skróty wszędzie tam, gdzie czyta człowiek. "Invalid member id" i podobne błędy mówią teraz, co poszło nie tak, zamiast podawać nazwę zmiennej. Wpisy w konsoli, z którymi bywały mylone, pozostały nienaruszone, bo one rzeczywiście są przeznaczone dla nas. Podobnie jak walidacja struktury API zwracana przy wywołaniach z poziomu kodu oraz kody maszynowe, na podstawie których Dashboard rozgałęzia logikę.
Wiadomości e-mail przeszły ten sam proces. Zaproszenie dla nieznajomego do dołączenia do "an organization" trafia prosto do kosza, dlatego powróciły wybrane przez Ciebie nazwy: konta, klucza, organizacji oraz osoby zapraszającej. Dowolny tekst wpisany przez klienta nadal nie trafia do żadnej wysyłanej przez nas wiadomości.
Pod maską
Browser powodował wyciek jednego deskryptora pliku na każdą sesję renderowania i nie działo się to z winy naszego kodu. Zależność upstream zamyka jeden ze swoich dwóch deskryptorów logów, po czym wykonuje wcześniejszy return i pomija drugi, ale tylko wtedy, gdy wywołujący przekazuje własny katalog profilu. Przekazujemy go przy każdym uruchomieniu, co czyniło wyciek pewnym i trwałym.
Łatka opakowuje tę pojedynczą metodę zamiast forkowania całej zależności. Najpierw uruchamia oryginał i działa tylko wtedy, gdy deskryptor jest nadal otwarty. Dzięki temu w dniu, w którym upstream przeniesie tę linię przed return, nasza łatka po cichu stanie się operacją no-op. Testy odtwarzają wyciek przed zainstalowaniem łatki, więc plik jasno określa, przed czym chroni, zamiast tylko zapewniać, że wszystko jest w porządku.
Praktyczny efekt: długo działające instancje Browser utrzymują swoją wydajność, zamiast degradować się wraz z kolejnymi sesjami. Jeśli chcesz kontrolować, jak te sesje wyglądają na poziomie sieci, równolegle udostępniliśmy browser profiles.
Obie powyższe poprawki miały to samo źródło. Coś przeszło weryfikację, która nie była tą istotną: zielone testy, podczas gdy z każdego okresu znikała godzina, proces zgłaszający gotowość do pracy, mimo że wyczerpał jedyny zasób, którego potrzebował. Zielony status łatwo osiągnąć. Trudniejsze pytanie brzmi: co musiałyby zarejestrować Twoje narzędzia pomiarowe, aby zmienić status na czerwony, i czy w ogóle są w stanie to wykryć.