https://klikukliku.dev/pl/Recent content on Kliku KlikuHugoplTue, 24 Mar 2026 00:00:00 +0000https://klikukliku.dev/pl/posts/pomodoro-technique/Tue, 24 Mar 2026 00:00:00 +0000https://klikukliku.dev/pl/posts/pomodoro-technique/<h2 id="wstęp">Wstęp</h2> <p>Zastanawialiście się kiedyś, dlaczego po kilku godzinach ciągłego pisania kodu nasza produktywność drastycznie spada? Zauważyłem u siebie, że największym wrogiem skupienia nie jest brak wiedzy. Jest nim ciągłe przełączanie kontekstu. Komunikatory, maile i szybkie pytania od kolegów wybijają nas z rytmu. Postanowiłem poszukać rozwiązania i przez ostatnie tygodnie testowałem technikę Pomodoro. Chcę się dzisiaj podzielić z wami moimi wnioskami.</p> <h2 id="na-czym-polega-to-podejście">Na czym polega to podejście?</h2> <p>Zasada działania jest bardzo prosta. Dzielimy nasz czas pracy na mniejsze, sztywno określone bloki. Najczęściej jest to dwadzieścia pięć minut pełnego skupienia na wyłącznie jednym zadaniu. W tym czasie wyciszamy powiadomienia i nie sprawdzamy poczty.</p>https://klikukliku.dev/pl/posts/opencode-in-docer-container/Tue, 17 Mar 2026 00:00:00 +0000https://klikukliku.dev/pl/posts/opencode-in-docer-container/<h2 id="wstęp">Wstęp</h2> <p>Ostatnio przyglądałem się tematowi bezpiecznego uruchamiania narzędzi AI bezpośrednio w naszym lokalnym środowisku. Narzędzia typu OpenCode są świetne, ale dają algorytmom dużą swobodę w operowaniu na naszych plikach. Zwykle kieruje się zasadą ograniczonego zaufania co skłoniło mnie do podjęcia próby zamknięcia opencode w kontenerze z dostępem do niezbędnych plików i katalogów.</p> <h2 id="dlaczego-izolacja-ma-znaczenie">Dlaczego izolacja ma znaczenie?</h2> <p>Kiedy pozwalamy modelom AI generować i uruchamiać kod, de facto oddajemy im częściową kontrolę nad terminalem. Nawet jeśli ufamy dostawcy, błąd w wygenerowanym skrypcie może narobić bałaganu w systemie plików. Rozwiązanie? <strong>Konteneryzacja</strong>.</p>https://klikukliku.dev/pl/posts/hugo-comments-cusdis/Tue, 10 Mar 2026 00:00:00 +0000https://klikukliku.dev/pl/posts/hugo-comments-cusdis/<h2 id="wstęp">Wstęp</h2> <p>Przeglądając systemy komentarzy do blogów statycznych, wziąłem na warsztat Cusdis — bo obiecuje podejście „minimum tarcia”: prosty widget, bez reklam i bez ciężkiej analityki w tle. Cusdis pozycjonuje się jako lekka, prywatnościowa alternatywa dla Disqus i jest rozwijany jako projekt open source, z opcją self-hostingu oraz wariantem zarządzanym na cusdis.com. Szczegółowy przewodnik po self-hostingu Cusdis znajdziesz w dedykowanym wpisie: <a href="https://klikukliku.dev/pl/posts/cusdis-self-hosted-vps">Self-Hosting Cusdis na VPS</a>.</p> <p>Moim celem było sprawdzić dwie rzeczy: jak wygląda sensowna integracja z Hugo (bez wklejania skryptów „na dziko”) oraz jaki realny narzut pojawia się na stronie, gdy komentarze są włączone.</p>https://klikukliku.dev/pl/posts/cusdis-custom-styles/Tue, 03 Mar 2026 00:00:00 +0000https://klikukliku.dev/pl/posts/cusdis-custom-styles/<h2 id="wstęp">Wstęp</h2> <p>Ostatnio przyglądałem się implementacji systemu komentarzy opartego na Cusdis. To lekkie i privacy-friendly rozwiązanie, ale ma jedną cechę, która z perspektywy UI jest wyzwaniem: widget renderuje się wewnątrz <code>iframe</code>.</p> <p>Co to dla nas oznacza? Iframe tworzy odizolowane środowisko. Style CSS, które mamy w naszym projekcie, nie &ldquo;przeciekają&rdquo; do środka. W efekcie, jeśli nasz layout ma specyficzny branding, domyślny, minimalistyczny wygląd Cusdis będzie wyglądał jak ciało obce.</p> <p>Przeanalizowałem ten temat i znalazłem sposób, by to obejść, zachowując czystość kodu.</p>https://klikukliku.dev/pl/posts/cusdis-self-hosted-vps/Tue, 24 Feb 2026 00:00:00 +0000https://klikukliku.dev/pl/posts/cusdis-self-hosted-vps/<h2 id="wstęp">Wstęp</h2> <p>Kiedy szukałem systemu komentarzy, szybko zdałem sobie sprawę, że większość dostępnych rozwiązań albo śledzi użytkowników, albo wymaga ciężkiego JavaScriptu, albo po prostu kosztuje. Cusdis wyróżnia się na tym tle. Jest lekki, open-source i od początku zaprojektowany z myślą o self-hostingu.</p> <p>W tym wpisie pokazuję, jak wdrożyć Cusdis na dowolnym VPS, używając Dockera i Caddy jako reverse proxy, z poprawnie skonfigurowanym CORS-em.</p> <h2 id="dlaczego-cusdis">Dlaczego Cusdis?</h2> <p>Zanim przejdę do konfiguracji, kilka słów o tym, co skłoniło mnie do wyboru właśnie tego narzędzia:</p>https://klikukliku.dev/pl/posts/hugo-comments-giscus/Tue, 17 Feb 2026 00:00:00 +0000https://klikukliku.dev/pl/posts/hugo-comments-giscus/<h2 id="wstęp">Wstęp</h2> <p>W ramach przeglądu rozwiązań do obsługi komentarzy na blogach statycznych, wziąłem na warsztat <strong>Giscus</strong>. To narzędzie typu open-source, które wykorzystuje GitHub Discussions jako swój backend.</p> <p>Zaintrygowała mnie przede wszystkim obietnica wydajności i prywatności.Poniżej przedstawiam analizę tego rozwiązania, instrukcję implementacji w Hugo oraz wnioski z testów wydajnościowych.</p> <h2 id="czym-właściwie-jest-giscus">Czym właściwie jest Giscus?</h2> <p>Giscus to widget, który łączy Twoją stronę bezpośrednio z API GitHuba. Kiedy czytelnik zostawia komentarz pod wpisem, system automatycznie tworzy nową dyskusję (lub dopisuje odpowiedź) w powiązanym repozytorium na GitHubie.</p>https://klikukliku.dev/pl/posts/hugo-comments-disqus/Tue, 10 Feb 2026 00:00:00 +0000https://klikukliku.dev/pl/posts/hugo-comments-disqus/<h2 id="wstęp">Wstęp</h2> <p>Disqus to prawdopodobnie pierwsze rozwiązanie, które przychodzi nam do głowy, gdy myślimy o komentarzach na stronach statycznych. Jest z nami od 2007 roku, obsługuje miliony witryn i zdejmuje z nas ciężar tworzenia własnego backendu.</p> <p>Postanowiłem sprawdzić, jak wygląda jego integracja z Hugo w 2026 roku, ale przede wszystkim, jaki jest rzeczywisty koszt tej wygody. Przeprowadziłem testy wydajnościowe na tym blogu i wyniki mogą was zaskoczyć.</p> <h2 id="czym-właściwie-jest-disqus">Czym właściwie jest Disqus?</h2> <p>W skrócie: to „komentarze jako usługa”. My dostarczamy statyczny frontend, a Disqus bierze na siebie całą brudną robotę: hosting bazy danych, walkę ze spamem, moderację i logowanie użytkowników (Google, Facebook, Twitter).</p>https://klikukliku.dev/pl/posts/hugo-performance-summary/Tue, 03 Feb 2026 00:00:00 +0000https://klikukliku.dev/pl/posts/hugo-performance-summary/<h2 id="wstęp">Wstęp</h2> <p>Przez ostatnie tygodnie przeszedłem przez kompleksową optymalizację mojej strony. Zaczęło się od prostej ciekawości czy da się wycisnąć więcej z tego generatora stron statycznych — a skończyło na serii eksperymentów, które dały wymierne rezultaty.</p> <p>Punkt wyjścia był naprawdę przyzwoity. Hugo z definicji generuje szybkie strony. Mój wynik w Lighthouse oscylował gdzieś między 92 a 94 punktami. Ale kiedy zagłębiłem się w Chrome DevTools i zerknąłem na szczegóły transferu sieciowego, zobaczyłem rzeczy, których gołym okiem nie widać. Prawie 15 megabajtów transferu na stronę główną. 15 osobnych plików CSS, które generowały półtorej sekundy opóźnienia. Zero strategii cache&rsquo;owania dla osób, które wracają na stronę.</p>https://klikukliku.dev/pl/posts/hugo-js-optimization/Tue, 27 Jan 2026 00:00:00 +0000https://klikukliku.dev/pl/posts/hugo-js-optimization/<h2 id="wstęp">Wstęp</h2> <p>Po <strong><a href="https://klikukliku.dev/pl/posts/hugo-css-optimization">uporządkowaniu stylów CSS</a></strong> i <strong><a href="https://klikukliku.dev/pl/posts/hugo-image-optimization">optymalizacji obrazów</a></strong>, zająłem się warstwą JavaScript. Na pierwszy rzut oka sytuacja wyglądała niewinnie. Strona ładowała dwa pliki: skrypt z motywu oraz mój własny kod obsługujący przełączanie koloru motywu. Łącznie ważyły one niespełna trzy kilobajty. Przy tak małym rozmiarze mogłoby się wydawać, że optymalizacja w tym miejscu to sztuka dla sztuki.</p> <p>Prawdziwe wyzwanie kryło się jednak w nagłówkach HTTP. Zauważyłem, że oba pliki miały ustawiony roczny czas życia w pamięci podręcznej. Niestety, w ich nazwach brakowało unikalnego identyfikatora, czyli tak zwanego fingerprintu. To stwarzało poważne ryzyko. Oznaczało bowiem, że po wdrożeniu jakichkolwiek poprawek, użytkownicy nadal korzystaliby ze starej wersji kodu zapisanej w przeglądarce.</p>https://klikukliku.dev/pl/posts/hugo-server-optimization/Tue, 20 Jan 2026 00:00:00 +0000https://klikukliku.dev/pl/posts/hugo-server-optimization/<h2 id="wstęp">Wstęp</h2> <p>Często skupiamy się na minifikacji HTML czy bundlingu CSS, uznając to za koniec optymalizacji. Zauważyłem jednak, że nawet najlepiej przygotowane pliki potrafią ładować się wolno, jeśli zapomnimy o warstwie serwera HTTP. To właśnie tam leży niewykorzystany potencjał, który warto zagospodarować.</p> <p>W mojej praktyce kluczowe okazują się dwa elementy konfiguracji. Po pierwsze, kompresja GZIP. Z mojego doświadczenia wynika, że potrafi ona zredukować rozmiar plików tekstowych o sześćdziesiąt do siedemdziesięciu procent. Po drugie, odpowiednie nagłówki Cache. Dzięki nim eliminujemy zbędne zapytania przy kolejnych wizytach użytkownika. Pokażę wam dzisiaj, jak skonfigurować serwer dla strony opartej na Hugo, aby wycisnąć maksimum możliwości ze statycznych plików.</p>https://klikukliku.dev/pl/posts/hugo-css-optimization/Tue, 13 Jan 2026 00:00:00 +0000https://klikukliku.dev/pl/posts/hugo-css-optimization/<h2 id="wstęp">Wstęp</h2> <p>Często skupiamy się na optymalizacji JavaScriptu czy obrazów, a style CSS traktujemy nieco po macoszemu. Wydaje nam się, że skoro pojedyncze pliki ważą zaledwie kilka kilobajtów, to nie stanowią problemu. Jednak to mylne założenie. Sposób, w jaki dostarczamy te pliki do przeglądarki, może mieć kluczowy wpływ na to, jak szybko użytkownik zobaczy gotową stronę.</p> <p>Kiedy zajrzałem do narzędzi deweloperskich w Chrome, zauważyłem u siebie konkretny problem. Moja strona ładowała aż piętnaście osobnych plików CSS. Sumarycznie generowało to opóźnienie rzędu jednej i sześciu dziesiątych sekundy. Co ciekawe, problemem wcale nie był rozmiar danych. Kompresja GZIP działała poprawnie i redukowała wagę plików o ponad sześćdziesiąt procent. Prawdziwym wąskim gardłem okazała się sama liczba zapytań HTTP. Przeglądarka traciła czas na nawiązywanie połączeń, zamiast na pobieranie treści.</p>https://klikukliku.dev/pl/posts/hugo-image-optimization/Tue, 06 Jan 2026 00:00:00 +0000https://klikukliku.dev/pl/posts/hugo-image-optimization/<h2 id="wstęp">Wstęp</h2> <p>Obrazy to zazwyczaj największa przeszkoda w osiągnięciu wysokiej wydajności stron internetowych. Choć Hugo generuje z natury szybkie witryny statyczne, nieoptymalizowane grafiki potrafią całkowicie zniweczyć tę przewagę. Postanowiłem przyjrzeć się temu bliżej na przykładzie własnej strony.</p> <p>Analiza w Chrome DevTools jasno wskazała źródło problemu. Obrazy stanowiły aż dziewięćdziesiąt sześć procent całego transferu, co dawało prawie piętnaście megabajtów danych. Namierzyłem trzy duże grafiki w formacie PNG, które generowały większość tego ruchu i wydłużały czas ładowania do ponad czterech sekund. Dla użytkowników mobilnych oznaczało to długie oczekiwanie i niepotrzebne zużycie pakietu danych.</p>https://klikukliku.dev/pl/posts/dockerfile-and-makefile-for-symfony/Tue, 30 Dec 2025 00:00:00 +0000https://klikukliku.dev/pl/posts/dockerfile-and-makefile-for-symfony/<h2 id="wstęp">Wstęp</h2> <p>Ostatnio sporo czasu poświęciłem na optymalizację mojego środowiska lokalnego. Zauważyłem, że sam wpadłem w pułapkę nadmiernej komplikacji. Tworzyłem rozbudowane pliki docker-compose i ukrywałem logikę w skryptach, przez co traciłem z oczu to, co najważniejsze. Postanowiłem wrócić do korzeni i postawić na prostotę. Moja obecna konfiguracja dla Symfony opiera się na dwóch filarach: czystym Dockerze i pliku Makefile. W samym obrazie deweloperskim postawiłem na najnowszą wersję PHP oraz wsparcie dla SQLite. Dzięki temu mogę wystartować z developmentem błyskawicznie, bez tracenia czasu na konfigurowanie ciężkich kontenerów z bazami danych.</p>https://klikukliku.dev/pl/posts/google-tag-manager-in-hugo/Tue, 23 Dec 2025 00:00:00 +0000https://klikukliku.dev/pl/posts/google-tag-manager-in-hugo/<h2 id="wstęp">Wstęp</h2> <p>Ostatnio musiałem zintegrować analitykę w jednym z projektów opartych na Hugo. Zazwyczaj wrzucenie skryptu śledzącego to &ldquo;pięć minut roboty&rdquo;, ale jeśli chcemy to zrobić porządnie – czyli wydajnie i z poszanowaniem prywatności użytkowników – sprawa robi się ciekawsza.</p> <p>Poniżej spisałem moje wnioski i gotową procedurę wdrożenia Google Tag Managera (GTM) oraz Google Analytics 4 (GA4). Skupiłem się na tym, aby kod był czysty, a mechanizm zgód na cookies (Cookie Consent) faktycznie działał, a nie tylko wyglądał.</p>https://klikukliku.dev/pl/posts/deploy-hugo-by-github-actions/Tue, 16 Dec 2025 00:00:00 +0000https://klikukliku.dev/pl/posts/deploy-hugo-by-github-actions/<h2 id="wstęp">Wstęp</h2> <p>Najprostszy sposób na automatyczne wdrażanie strony w Hugo wygląda tak: trzymamy cały projekt w repozytorium na GitHubie, a GitHub Actions po każdym pushu buduje stronę i wysyła wygenerowany katalog public/ na nasz serwer przez SSH z użyciem rsync.</p> <h2 id="założenia">Założenia</h2> <p>Zakładam tutaj dwie rzeczy.</p> <p>Po pierwsze, masz już lokalnie działający projekt Hugo. Na przykład utworzony komendą <code>hugo new site twoja_strona</code> i sprawdzony w ten sposób, że lokalne wywołanie komendy <code>hugo</code> poprawnie generuje katalog public/.</p>https://klikukliku.dev/pl/posts/hugo-vs-sulu/Tue, 09 Dec 2025 00:00:00 +0000https://klikukliku.dev/pl/posts/hugo-vs-sulu/<h2 id="wstęp">Wstęp</h2> <p>Dzisiaj weźmiemy na warsztat dwa narzędzia o zupełnie innej filozofii działania: Hugo oraz Sulu. Oba są rozwiązaniami typu open source, ale służą do rozwiązywania problemów w odmienny sposób.</p> <p>Zacznijmy od Hugo. To generator stron statycznych napisany w języku Go. Jego głównym zadaniem jest przetworzenie kodu na gotowe pliki HTML, CSS i JavaScript, które potem możemy wystawić na dowolnym serwerze. To, co wyróżnia Hugo, to przede wszystkim niesamowita szybkość budowania witryny. Społeczność wokół tego projektu dynamicznie rośnie i zgromadziła już ponad osiemdziesiąt pięć tysięcy gwiazdek na GitHubie. Muszę jednak zaznaczyć, że jest to narzędzie typowo deweloperskie. Edycja treści opiera się tu głównie na plikach Markdown i systemie kontroli wersji Git, co wymaga pewnej biegłości technicznej.</p>https://klikukliku.dev/pl/readme/Mon, 01 Jan 0001 00:00:00 +0000https://klikukliku.dev/pl/readme/<h2 id="cześć">Cześć!</h2> <p>Mówią, że startując z projektem, trzeba mieć strategię. Ja na razie mam tylko chęci i klawiaturę.</p> <p>Nie wiem jeszcze, czy to będzie techniczny poradnik, czy dziennik developera. Na ten moment traktuję to miejsce jako moją „zewnętrzną pamięć”. Zbieram tu rozwiązania i pomysły, które chcę zachować na przyszłość, żeby nie musieć szukać ich dwa razy.</p> <p>A skoro już to spisuję – niech służy też innym.</p>https://klikukliku.dev/pl/pomodoro/Mon, 01 Jan 0001 00:00:00 +0000https://klikukliku.dev/pl/pomodoro/