Ale ten czas leci. Myślałem, że od ostatniego wpisu minął równy miesiąc, a jednak nie: poprzednie podsumowanie czego nowego się nauczyłem robiłem dokładnie 15 lutego.
Uznajmy, że 28 marca to już koniec miesiąca, więc mogę zrobić kolejne podsumowanie. Spojler alert: tym razem nowości jest mniej.
Wykorzystałem Astro
Jak wcześniej wspominałem, że polubiłem Astro, to od tamtej pory przeniosłem stronę Gajówka Pasieki na ten system. Jak widać to jest niewiarygodnie prosta strona (i powstała w jeden wieczór gdy przy piwie stwierdziliśmy z kolegą, że taka strona musi powstać), gdzie na WordPressie był zainstalowany gotowy motyw, dodane trzy podstrony i przez lata nic innego tam się nie pojawiało. WordPress jest do tego absolutnie zbędny i tylko sprawiał problem, bo raz, że trzeba go było co chwila aktualizować, a dwa generowanie w kółko tych samych trzech widoków przez PHP to marnotrawstwo zasobów. To powinno być statyczne i jest statyczne (i wyświetla się dwa razy szybciej, choć całość jest teraz hostowana na darmowym GitHub Pages)
Coolify
A wiecie, że od 12 lat jestem posiadaczem serwera dedykowanego, z którego właściwie nie korzystam? Nie VPS tylko prawdziwy metalowy rack siedzi sobie w szafie w serwerowni we Francji i ma 500 GB przestrzeni, z której właściwie nie korzystam. Raz na jakiś czas coś instaluje i potem to kasuje.
Mam go tak długo, bo jest głupio tani. Gdy serwery dedykowane potrafią kosztować ponad tysiąc złotych za miesiąc, to ja za niego płacę coś około 25 złotych miesięcznie. To jest Kimsufi od OVH i tyle właśnie one kosztują w najtańszych wersjach. Są wolne, ale w takiej cenie idealne do nauki administrowania zdalnym serwerem.
Są wolne, ale dobre pod strony statyczne. Postanowiłem więc podejść do tego jako do miejsca na moje przyszłe strony w Astro więc dość naturalnie zainteresowałem się Coolify. To taki odpowiednik open source Netlify, gdzie masz panel w przeglądarce do tworzenia różnych instancji serwerów i uruchomionych tam usług (WordPressa też można).
Działa to tak na 4+. UI mogłoby być miejscami lepsze, czasem składanie wszystkich klocków (repozytoriów gita, zasobów do deployu, zarządzanie kluczami SSH) nie jest intuicyjne i zdarza się, że muszę jakąś instancję zabić i zacząć od nowa. Ostatecznie mam tam już dwie działające “próbki” czegoś tam.
Programiści Google to tacy sami ludzie jak my
…i im też zdarzają się fuckupy i to takie że ho. Wiecie, że stworzyli oni nowe Places API, wyłączyli stare Places API i nie zauważyli, że te stare wciąż jest wymagane gdy używasz go w połączeniu JavaScript Maps API (a właściwie każdy kto dodaje mapę na stronę używa takiego połączenia)?
To było tak niesamowite doświadczenie, że miałem totalny mindfuck, gdy klienci zaczęli nam to w pracy zgłaszać. Że nasza wtyczka, która wyświetla mapy zaczęła źle działać. No googlowych forach inni programiści zaczęli to zgłaszać Googlowi a ich programiści bardzo pokrętnie zaczęli tłumaczyć, by używać już tylko nowego Places API. Że może to takie trochę z zaskoczenia zmiana, ale sorry i tak trzeba. Co więcej widząc, że nowe API ma błędy na szybko je łatali i kazali używać API w wersji z kanału alpha.
Jako, że naszej wtyczki używa tak pi razy oko kilkaset tysięcy ludzi, musiałem to wszystko na szybko przepisywać na nowe API. I była to bardzo dziwna droga i doświadczenie: co chwila trafiałem na jakąś niekonsekwencję, nieporozumienia w komunikacji między Places API, a Maps JavaScript API, a do tego jeszcze Geocoding API, które musiałem łatać po omacku na poziomie naszej wtyczki (gdy to absolutnie leżało po stronie domeny Googla). Im dalej, tym więcej rzeczy nie działało.
Na szczęście trwało to tylko dla mnie kilka dni, po których odkryłem, że jak gdyby nigdy nic stare API wróciło. Ktoś tam jednak zauważył, że to jest katastrofa.
Ale nadal nie wierzę, że tak wielkie korpo, które uczy innych jak dbać o jakość kodu, pokrywać wszystko testami itd nie tylko przegapiło, że ich nowe API źle działa, to było tak pewne swojego, że stare zwyczajnie z dnia na dzień wyłączyli (a raczej ukryli). To był dla mnie spory dysonans poznawczy.
Claude CLI
Rozwiązując powyższy problem, próbowałem użyć Claude CLI. Ostatecznie poległ (a właściwie przewidział przyszłość: w pewnym momencie z uporem maniaka podawał rozwiązania w starszej wersji API) ale samo oglądanie jak pracuje robiło przyjemne i imponujące wrażenie. Podałem mu prompt w konsoli, by obniżyć koszt podpowiedziałem w jakim katalogu mam kod, podałem linki do forów gdzie inni opisywali ten sam problem.
Mielił, myślał, zaglądał pod linki i zaczął podawać rozwiązania od razu zmieniając mój kod. Oczywiście to nie działało i mówiłem mu jakie tym razem mam błędy w konsoli, nawet podałem mu link do mojej strony na localhoscie mając nadzieję, że może będzie umiał sam zauważyć błąd.
I tu było najlepsze: gdy zorientował się, że to jest localhost, sam zaczął pisać sample strony zawierające kod JS jaki chce mi zaproponować, umieszczać na moim serwerze i uruchamiać na nim automatyczne testy sprawdzające czy to co chce zaproponować będzie działać. Po kilku takich próbach właśnie zauważył, że nic nie działa i to wtedy stwierdził, że jedyne co możemy zrobić to używać stare API.
Sprytna bestia, nawet jak nie zna rozwiązania.