Dzień 27.

  Od wejścia do pracy, PM chciał ze mną pogadać. Czytaj zapytać jak postępują prace. Chciałem pokazać jak postępują a tu jeb, Internal Server Error 500 na głównej. Mówię, że to bardzo ciekawe, bo jeszcze wczoraj wszystko działało, więc klikam na podstronę z listą ludzi. Wyświetla się, ale już naciśnięcie mojego nowego przycisku do generowania pdf-a z etykietami adresowymi się wywala. No nic myślę, pokażę co się wygeneruje z CLI. Odpadam komendę i bum! Znowu coś. I wtedy sobie przypomniałem, że wczoraj przed wyjściem kolega poprosił, żebym przeskoczył do brancha develop i zrobił pulla a później odpalił builda. Zrobiłem, działało i poszliśmy do domu. Dzisiaj sobie zdałem sprawę, że ten build wywalił w kosmos moją bazę, ale za to w prezencie mam aktualniejsze dane... No super, ale ja w swojej bazie miałem już znane osoby ze znanymi mi ustawieniami do testowania. No nic - myślę - trzeba zrobić mig, mig jak Struś Pędziwiatr (czytaj ./app/console doc:mig:mig -n). Migracja się udała, uruchamiam skrypt do generowania pdfów i jeb ponownie. Tym razem brakuje atrybutu "gender" w encji. PM-owi mówię, że zabiję kolegę, który mnie wczoraj namówił na tego pulla, ale że mogę mu chociaż pokazać resztki z wczoraj. Pokazałem jak mniej więcej wygląda jedna strona tego pdf-a z naklejkami adresowymi. Pokiwał głową i powiedział, żebym sobie teraz spokojnie naprawiał system. Coś mi w głowie świtało, że koleżanka juniorka z biurka obok rozmawiała z kimś o kwestiach genderowych, więc spytałem czy czasem ktoś nie usunął gendera z bazy. No i okazało się, że usunął, więc ponownie pożałowałem wczorajszego pulla. Nie chciałem się bawić w cofanie migracji albo kopiowanie kodu z głównego brancha, więc szybko zakomentowałem atrybut gender w encji i aplikacja ruszyła. Do czasu... gdy nie wszedłem w edycję osoby i znowu sie wysypała, więc ponownie musiałem stoczyć gender-war. Jakoś się udało, więc puściłem generowanie pdf-a dla 500+ obiektów i zawołałem PM-a. Założeniem było 3 na 8 naklejek na jednej kartce papieru, więc zaczęły się problemy z paginacją i przesuwaniem się naklejek na kolejnych stronach. Wpadliśmy na pomysł, żeby znaleźć rozdzielczość w pikselach w 72 dpi dla kartki formatu A4. Podzieliłem to na 8 i wyszedł ułamek 105,25. Podejrzewałem, że ustawienie w css-ie height na 105.25px raczej nie zadziała, bo ciężko o ćwiartkę piksela i tak też się stało. Zawołaliśmy jedynego obecnie front-endowca, żeby coś podpowiedział, ale też na początku stwierdził, że lekko nie będzie i na pewno ćwierć piksela się nam nie wyświetli. Zaproponował skorzystanie z selektora nth-child(8) i wstawienie tam pustego diva o wysokości 2 pikseli, ale do tego trzeba było moje pojedyncze divy sklejane ze sobą bokami przerabiać na rzędy i w tym czasie kolega wpadł na prostszą metodą, czyli:

{% if index.loop % 24 == 0 %}

    <div class="spacer"></div>

{% endif %}

po stronie twiga, gdzie klasa "spacer" miała wysokość ustawioną na 2px. Dodaliśmy jeszcze testowo czerwone tło i pięknie nam ten "spacer" pojawiał się dokładnie na końcu każdej kartki. Chwilę później wykorzystałem też nowo nabytą wiedzę o index.loop, żeby policzyć liczbę naklejek.

  Trochę jeszcze poklikałem, wszystko działa i super, no to pora na test na nieco większej liczbie adresatów niż 500+. Żeby mieć odpowiedni rozmach, zaznaczyłem wszystkie osoby w bazie, a więc 43000+ i kliknąłem "Wygeneruj etykiety". Wcześniej, po chwili pojawiał się modal, który zrobiłem, z informacja, że rozpoczął się proces generowania. Teraz czekam i zerkam na devtools z przeglądarki, a tam wisi sobie szary POST i wisi. Czekam, czekam, w końcu się zazielenił i pojawił sie wyczekiwany modal. Czas oczekiwania na odpowiedź na ten request wyniósł ponad 7 sekund, no ale cóż... Uruchamiam więc proces generowania etykiet w konsoli. Pojawia się status, że przystępuje do generowania ponad 26000 naklejek. Czemu o tyle mniej? Otóż nie wszyscy z tej bazy wyrażają chęć otrzymywania korespondencji, więc bez sensu dla nich robić naklejki skoro nic im nie będą wysyłać. Czekam, czekam, sruuu, coś na czerwono. Patrzę a tam timeout większy niż 60 s i do widzenia. No to szukam o co chodzi, ale okazuje się, że nie tylko ja, bo innym też się skrypty wywalają z takim timeoutem. Szukam skąd to się bierze i nie była to komenda konwertera, tylko mechanizm Symfony. Próbowałem to obejść przez plik pośredni, ale na nic się to zdało. Wreszcie zaczęliśmy grzebać razem i okazało się, że ten timeout jest na sztywno ustawiony i niby jest metoda setTimeout(), tylko szkoda, że prywatna. Kolega dorwał się więc do klawiatury i shackował system pisząc wrappera wokół oryginalnego generatora pdf-ów. Po kilku poprawkach zaczął działać, więc wygenerowałem te tysiące etykiet i otworzyłem pdf-a. 1097 stron pełnych nazwisk i adresów robi wrażenie. Pewnie jeszcze większe zrobi na drukarce, które je dostanie do wydruku. Czas oczekiwania wyniósł ponad 900 sekund przy odpaleniu komendy systemowej do konwertera, a tutaj ze skryptu trochę dłużej, ale to dopiero początek zmartwień. Teraz kolejny etap - sortowanie. Klient zażyczył sobie, aby najpierw były naklejki dla mieszkańców Warszawy. I teraz się zaczęło szukanie sposobu jak to zrobić najlepiej. Najpierw poległem na próbie stworzenia zapytania przy użyciu QueryBuildera, bo przerosła mnie liczba encji do skakania (ponownie). Kolega zaproponował metodę usort(), ale też miałem problem z napisaniem callbacka, więc zrobił to za mnie. Zadziałało na małej próbce, więc odpaliliśmy na większej. Długo to trwało, więc przerwałem skrypt po 20 minutach, bo w zasadzie nie byłem pewien na jakim etapie wisi. Dodałem więcej informacji co krok i odpaliłem ponownie. Zatrzymał się na sortowaniu. 15 minut później poszedłem do domu i zostawiłem włączony komputer. Czekam na jutrzejsze niespodzianki i kombinowanie co z tym zrobić. Zwłaszcza, że zostało mi w tym zadaniu jeszcze trochę do dopisania i chciałbym to wreszcie jutro skończyć, więc liczę, że całkowity czas generowania takiego dużego pdf-a będzie w miarę znośny...