Duży klient B2B miał na stronie wiele różnych formularzy – jedne do kontaktu, inne pod webinary, jeszcze inne pod eventy VIP. Za każdym razem gdy marketing chciał dorzucić nowe pole albo zmienić etykietę, dzwonili do developera. Za każdym razem znaczyło to godzinę pracy – napisanie kodu, testy, deploy. Za każdym razem koszt.

Do tego wszystkie te formularze musiały trafiać do jednego systemu marketing automation, który obsługuje cały pipeline sprzedażowy klienta. System ten trzyma się mocno swoich standardów: konkretny endpoint, konkretne nazwy pól, konkretny format.

Zadanie było proste do sformułowania, trudne do zrobienia dobrze: zbudować w WordPressie jeden uniwersalny blok formularza, w którym marketing sam sobie ustawia pola przez interfejs administracyjny, bez ruszania kodu. A dane i tak zawsze prawidłowo trafiają do systemu marketing automation.

Co zrobiłam

Podeszłam do tego jako bloku ACF w Gutenbergu. Blok ma konfigurowalny repeater „Pola formularza” – marketing dodaje sobie pole, wybiera typ (tekst, email, telefon, select, textarea), ustala etykietę, decyduje czy jest wymagane. Dla pól typu select wpisuje opcje jedna pod drugą. Do tego osobne pola konfiguracji: zgody użytkownika (repeater z tekstem RODO), URL endpoint’a systemu marketing automation, opcjonalne pola ukryte przekazywane do systemu (np. identyfikator kampanii), komunikaty (sukces, błąd, walidacja).

Formularz na froncie generuje się dynamicznie z tej konfiguracji. Marketing dodał pole – pole pojawia się na stronie. Zmienił etykietę – etykieta się zmienia. Zero developera.

Bypass CORS przez ukryty iframe

Największy problem techniczny był z wysyłaniem danych do systemu marketing automation. Endpoint tego systemu jest na innej domenie niż strona klienta, a CORS blokuje bezpośredni POST z JavaScript. Można to obejść przez proxy po stronie WordPressa, ale wtedy tracimy kontekst przeglądarki (ciasteczka trackingowe systemu marketing) – a to psuje przypisywanie leadów do kampanii.

Rozwiązanie: ukryty iframe. Skrypt tworzy w tle niewidoczny formularz HTML z akcją prowadzącą do endpoint’a marketing automation i celem submitu na ukryty iframe. Wysyłamy submit, przeglądarka wykonuje POST natywnie (jakby to był normalny formularz), CORS nie ma tu nic do gadania bo to nie fetch tylko form submit. Odpowiedź ląduje w iframe i my jej nie odczytujemy – ale nie musimy, bo system marketing automation ma po swojej stronie logikę i tak.

function submitToMarketingAutomation(form, endpointUrl, onDone) {
    var iframeName = 'cf-iframe-' + Date.now();
    var iframe = document.createElement('iframe');
    iframe.name = iframeName;
    iframe.style.display = 'none';
    document.body.appendChild(iframe);

    var tempForm = document.createElement('form');
    tempForm.method = 'POST';
    tempForm.action = endpointUrl;
    tempForm.target = iframeName;
    tempForm.style.display = 'none';

    // ... zebranie pól z oryginalnego formularza i dodanie do tempForm

    document.body.appendChild(tempForm);
    tempForm.submit();

    setTimeout(function () {
        onDone();
        if (tempForm.parentNode) tempForm.parentNode.removeChild(tempForm);
        if (iframe.parentNode) iframe.parentNode.removeChild(iframe);
    }, 2000);
}

Agregacja pól o tej samej nazwie

System marketing automation klienta ma ograniczenie: jest jedno pole „Comments” na wszystkie dodatkowe informacje. Marketing chciał w formularzu mieć trzy osobne pola widoczne dla użytkownika – dietę, NIP, dodatkowego uczestnika – ale w systemie muszą trafić jako jeden ciąg tekstu.

Zrobiłam to przez konwencję: w konfiguracji ACF marketing wpisuje wszystkim trzem polom tę samą nazwę marketing automation („Comments”), a JavaScript przed submitem zbiera je w mapę, łączy w string z etykietami rozdzielony pionową kreską:

var fieldMap = {};
var fields = form.querySelectorAll('input, select, textarea');

fields.forEach(function (field) {
    if (!field.name || !field.value) return;

    var name = field.name;
    var label = getLabelForField(field);

    if (!fieldMap[name]) fieldMap[name] = [];
    fieldMap[name].push({ label: label, value: field.value });
});

// Zbuduj hidden inputs
Object.keys(fieldMap).forEach(function (name) {
    var entries = fieldMap[name];
    var input = document.createElement('input');
    input.type = 'hidden';
    input.name = name;

    if (entries.length === 1) {
        input.value = entries[0].value;
    } else {
        // Wiele pól o tej samej nazwie - zlep w jeden string
        // Format: "Dieta: Wegetarianska | NIP: 1234 | Dodatkowy: Anna"
        var parts = entries.map(function (e) {
            return e.label + ': ' + e.value;
        });
        input.value = parts.join(' | ');
    }
    tempForm.appendChild(input);
});

Dlaczego setTimeout, a nie iframe.onload

Pokusa użycia zdarzenia iframe.onload do wykrycia momentu odebrania odpowiedzi przez system marketing automation jest duża, ale w praktyce nie zadziała. Ponieważ endpoint działa na innej domenie niż WordPress, wchodzi w grę polityka Same-Origin Policy. Przeglądarka odpala zdarzenie onload na ramce iframe od razu przy jej utworzeniu (dla pustego dokumentu about:blank), albo blokuje zdarzenie całkowicie po wysłaniu cross-origin POST. Nie ma stabilnego sposobu żeby „podsłuchać” moment, w którym zewnętrzny serwer skończył przetwarzać submit.

Kontrolowane opóźnienie czasowe (setTimeout) jest w tym scenariuszu najbardziej niezawodnym kompromisem produkcyjnym. Alternatywa – proxy po backendzie WordPressa – działałaby, ale kosztem dodatkowej warstwy infrastruktury i utraty kontekstu ciasteczek trackingowych systemu marketing automation.

Świadome ograniczenia

Nie wszystko warto było automatyzować. Świadomie zdecydowałam, że nie robię własnej warstwy walidacji odpowiedzi z systemu marketing automation. Iframe cross-origin i tak nie pozwala odczytać odpowiedzi (CORS blokuje), więc alternatywą byłoby proxy po backend’zie – a to komplikacja której nie potrzebowaliśmy. Zamiast tego formularz zawsze pokazuje „Dziękujemy” po 2 sekundach od submitu (analogicznie do innych formularzy klienta, które od dawna działają w ten sam sposób).

Konsekwencja: jeśli system marketing automation odrzuci submit (np. zły format email), użytkownik i tak zobaczy „Dziękujemy”. W praktyce się to nie zdarza – front-end waliduje wymagane pola przed submitem, a system marketing dostaje tylko poprawne dane. Ryzyko akceptowalne w zamian za brak dodatkowej warstwy infrastruktury.

Efekt

Marketing dodaje sobie nowe formularze bez developera. Wystarczy wrzucić na stronę blok „Custom Form”, skonfigurować pola, wpisać endpoint systemu marketing automation – gotowe. Zmiana etykiety w polu „Nazwa firmy”? 30 sekund w wp-admin, bez commita, bez deploya.

Dane trafiają do jednego systemu marketing automation w jednolitym formacie. Zgody użytkownika są konfigurowalne (RODO wymaga elastyczności w formułowaniu zgód pod różne kanały). Formularz pod webinar, formularz kontaktowy, formularz eventu – wszystko przez ten sam blok, wszystko trafia gdzie ma trafić.

Od strony developera – jeden blok do utrzymywania, jeden JS do debugowania. Zamiast pięciu różnych implementacji dla pięciu różnych formularzy – jeden reusable komponent.

Artykuł Konfigurowalny formularz ACF wysyłający dane do systemu marketing automation pochodzi z serwisu MultiTask Creations.

Pierwsza wersja tej strony powstała z odwagi. Napisałam o tym osobno – o perfekcjonizmie, który blokował, i o tym, że w końcu nacisnęłam „publikuj”. Postawiłam ją na WordPressie z Elementorem, bo wtedy to było rozsądne: szybko, widać efekt, można ruszyć dalej.

Ale strona żyje razem z tym, kto ją prowadzi. Po kilkunastu projektach dla klientów zaczęłam patrzeć na własną witrynę inaczej. Widziałam rzeczy, których wcześniej nie widziałam: że układ jest z gotowca, a nie z pomysłu. Że treści są, ale nie mówią tego, co chcę powiedzieć. Że gdybym dziś dostała siebie jako klientkę, doradziłabym coś innego.

Do tego doszły dwie rzeczy praktyczne. Po pierwsze – dwa języki. Chciałam, żeby wersja angielska nie była doklejona, tylko równorzędna. Po drugie – treści z panelu. Nie chciałam wchodzić w kod za każdym razem, gdy zmienia się cena albo dochodzi nowa realizacja.

Co zrobiłam

Zrezygnowałam z Elementora i napisałam motyw od zera. To była świadoma decyzja, nie kaprys. Na wizytówkę klienta Elementor często jest w porządku – pisałam o tym w poradniku o wyborze motywu. Ale ta strona jest moim portfolio: ma być lekka, ma wyglądać tak, jak chcę, i ma pokazywać, że potrafię więcej niż poskładać klocki.

Fundament to autorski motyw WordPress: własne szablony dla strony głównej, podstron oferty, realizacji i bloga. Zero page buildera, zero martwego kodu, którego nikt nie użyje. Same style i skrypty, których strona faktycznie potrzebuje.

Treści wyciągnęłam do pól ACF – każdy nagłówek, lead, pakiet czy krok procesu edytuję z panelu, bez dotykania kodu. Wygląda to jak w projektach, które robię klientom: wchodzisz w edycję strony i widzisz konkretne, opisane pola, a nie labirynt klocków.

Dwujęzyczność oparłam na Polylang. Każda strona, realizacja i wpis mają swój odpowiednik angielski, spięty tłumaczeniem. Menu, przełącznik języka, przyciski – wszystko prowadzi tam, gdzie powinno, bez gubienia się między wersjami.

Doszło kilka rzeczy, których wcześniej nie było: osobny typ treści na realizacje (z filtrem po rodzaju usługi), wizualna galeria żywych stron z karuzelą, sekcje opinii, pakiety opieki. I drobiazgi, których nikt nie zauważy, dopóki ich nie zabraknie – jak automatyczne sklejanie sierotek czy akcent kolorem w nagłówkach:

// Nagłówek z akcentem: *słowo* dostaje kolor marki
function mt_acc_heading( $text ) {
    if ( strpos( $text, '*' ) !== false ) {
        return preg_replace( '/\*(.+?)\*/u', '<em class="acc">$1</em>', esc_html( $text ) );
    }
    // bez gwiazdek: akcent na ostatnim słowie
    return mt_orphans( $text );
}

Najwięcej pracy poszło jednak nie w kod, a w treść. Przeszłam stronę po stronie, realizację po realizacji. Wyrzuciłam to, co brzmiało jak z szablonu, i napisałam to, co naprawdę chcę powiedzieć – konkretnie, bez owijania, z liczbami tam, gdzie są. Każdy tekst dostał swoją wersję angielską i własne SEO.

Efekt

Strona jest lżejsza, szybsza i w końcu moja – nie poskładana z gotowca, tylko zbudowana pod to, co robię. Wersja angielska jest równorzędna, a nie doklejona. Treści zmieniam z panelu w minutę.

Ale najważniejsze jest coś innego. Ta przebudowa to dowód na to, co powtarzam klientom: strona to proces, nie pomnik. Pierwsza wersja nie była błędem – była dobrym pierwszym krokiem, który przez lata robił swoje. Druga powstała, bo urosłam z tamtej. I pewnie kiedyś będzie trzecia.

Jeśli zastanawiasz się, czy Twoja strona wymaga przebudowy – odpowiedź brzmi zwykle: nie od razu. Warto ją zrobić wtedy, gdy zaczyna przeszkadzać, a nie wtedy, gdy pojawi się nowa moda. U mnie ten moment po prostu nadszedł. Historię pierwszej wersji opisałam tutaj.

Artykuł Druga wersja: przebudowa własnej strony pochodzi z serwisu MultiTask Creations.

Jak pokazać dane o bezdomności psów tak, żeby ludzie chcieli je czytać? To było moje wyzwanie.

W marcu 2026 zgłosiłam się jako wolontariuszka do drugiej edycji akcji #BI_NGO, organizowanej przez Język Danych – inicjatywy, która łączy ludzi z branży danych z organizacjami pozarządowymi. Fundacje dostają profesjonalne wizualizacje, a uczestnicy realny projekt do portfolio. Serdecznie zachęcam do udziału – to dopiero druga edycja i mam nadzieję, że nie ostatnia. Wszystkie prace z akcji można zobaczyć w galerii #BI_NGO.

Moim zadaniem była wizualizacja danych dla Working Dogs Foundation – fundacji, której misją jest poprawa standardu życia psów przez edukację ludzi. Tak powstała „Droga Psa”: data storytelling, który opowiada historię bezdomności psów jak artykuł – prowadzi odbiorcę przez liczby, programy fundacji i cytaty ludzi, których życie zmieniła adopcja. Dane pochodzą z czterech różnych źródeł: GIW, Working Dogs Foundation, FEDIAF i badania Karmimy Psiaki.

Co zrobiłam

„Droga Psa” to nie sucha tablica z wykresami, ale narracja – taka, którą czyta się jak reportaż. Złożyłam ją z kilku elementów, z których każdy prowadzi odbiorcę o krok dalej:

Interaktywny wykres trendu adopcji 2015-2024 z tooltipem – pokazuje, jak zmieniała się liczba adopcji na przestrzeni lat.

Animowana wizualizacja ikonowa, gdzie każda ikona to 1000 psów – skala problemu, którą widać na pierwszy rzut oka.

Do tego karuzela zdjęć z płynną pętlą i lightboxem, slider cytatów beneficjentów oraz animowane paski wzrostu liczby wolontariuszy i darczyńców. Dane finansowe wyraźnie oznaczyłam tam, gdzie były estymacją – bo uczciwość wobec liczb jest tu równie ważna jak sama wizualizacja.

Wyzwania techniczne. Wszystkie wykresy i animacje napisałam ręcznie, w czystym JavaScript – bez żadnych bibliotek. Najtrudniejsze okazały się dwie rzeczy: karuzela z płynną, nieskończoną pętlą oraz synchronizacja danych z czterech źródeł, z których każde zbierało je inną metodologią.

Efekt

Powstała wizualizacja, która nie zanudza tabelami, tylko wciąga – i realnie służy fundacji w opowiadaniu o swojej misji. Stack: HTML · CSS · JavaScript (vanilla) · PHP.

Projekt powstał z myślą o konkretnej fundacji, ale podejście jest zawsze takie samo: dostarczam rozwiązanie dopasowane do realnych potrzeb i możliwości odbiorcy. A przy okazji – jeśli możesz pomóc, pomagaj. Warto.

Artykuł Droga Psa – data storytelling dla Working Dogs Foundation pochodzi z serwisu MultiTask Creations.

Późny wieczór. Na ekranie działający prototyp aplikacji mobilnej – owoc miesięcy samodzielnej pracy. Technicznie rdzeń działa: można przeglądać dane, klikać, zapisywać. A mimo to w powietrzu unosi się frustracja.

Aplikacja działała, ale nie miała „duszy”. Była zbiorem połączonych funkcji, a nie spójnym, intuicyjnym doświadczeniem. Przepływy użytkownika nielogiczne, interfejs toporny, najlepsze pomysły gubiły się po drodze. To był ten bolesny moment, gdy widać, że ogromny potencjał projektu jest uwięziony w kodzie, który „po prostu działał” – zamiast zachwycać.

Co zrobiłam

Mogłam dalej „łatać” i dodawać funkcje do istniejącej struktury. Ale to droga donikąd – aplikacja potrzebowała operacji na otwartym sercu. Celem było przekształcenie obiecującego prototypu w profesjonalny, gotowy na rynek produkt (MVP+) z fundamentami na lata. Podzieliłam to na trzy filary:

• Architektura – czysta, skalowalna struktura ułatwiająca dalszy rozwój.
• UX – przeprojektowanie kluczowych procesów, żeby były intuicyjne i satysfakcjonujące.
• Strategia – jasna mapa drogowa, żeby rozwój był przemyślany i uporządkowany.

Wybrałam nowoczesny stos: Flutter (szybki rozwój na iOS i Androida), Riverpod (zarządzanie stanem) i Firebase (bezserwerowy backend od Google).

Dobrym przykładem nowej architektury jest nawigacja. Zamiast chaotycznych warunków rozrzuconych po kodzie – centralny system oparty na pakiecie go_router. To „mózg”, który dba, żeby użytkownik zawsze trafiał we właściwe miejsce zależnie od stanu: czy jest zalogowany, czy zweryfikował e-mail, czy ukończył wdrożenie:

// Fragment logiki przekierowań w aplikacji
redirect: (BuildContext context, GoRouterState state) {
  final user = _auth.currentUser;
  final isLoggedIn = user != null;
  final isPublicRoute = state.matchedLocation == '/login' || state.matchedLocation == '/register';
  // Niezalogowany -> tylko ścieżki publiczne
  if (!isLoggedIn) {
    return isPublicRoute ? null : '/login';
  }
  final isVerified = user.emailVerified;
  // ... (dalsza logika weryfikacji i onboardingu) ...
  if (isPublicRoute) {
    return '/home';
  }
  return null;
},

Efekt

Solidne fundamenty pozwoliły na błyskawiczny rozwój. W kilka tygodni zrealizowałam 5 głównych kamieni milowych, naprawiłam kilkanaście błędów UX, wdrożyłam złożone funkcje (trzy różne widoki kluczowego ekranu, system grywalizacji) i osiągnęłam 100% gotowości wersji testowej 1.1. Aplikacja odzyskała „duszę”.

Największą satysfakcję dało mi nie samo kodowanie, ale ciągła synergia między wizją produktu a ekspertyzą techniczną. Najlepsze aplikacje nie powstają w próżni – rodzą się w cyklu otwartej, iteracyjnej pracy, gdzie każda informacja zwrotna prowadzi do lepszego rozwiązania.

Artykuł Od prototypu do żywej aplikacji pochodzi z serwisu MultiTask Creations.

Każdy freelancer zna różne typy klientów. Są tacy z gotową, szczegółową wizją, i tacy z mglistym zarysem pomysłu. A czasem trafia się ktoś, kto mówi po prostu: „Potrzebuję strony. Ufam Pani, proszę zrobić tak, żeby było dobrze”.

To zdanie to jednocześnie ogromny kredyt zaufania i wielkie twórcze wyzwanie. Właśnie z takim zadaniem zmierzyłam się przy stronie-wizytówce dla firmy budowlanej Step-Bud. Klient nie miał konkretnego pomysłu, podesłał tylko link do jednej strony, która była „w miarę OK”. Reszta należała do mnie – czysta karta i szansa na stworzenie czegoś od podstaw.

Co zrobiłam

W budownictwie liczą się solidność, profesjonalizm i zaufanie – strona musiała odzwierciedlać dokładnie te cechy. Celem nie była sama wizytówka, ale cyfrowy fundament biznesu: miejsce, które od progu wzbudza zaufanie i przejrzyście pokazuje jakość pracy. Postawiłam na sprawdzonego WordPressa – rusztowanie, na którym zbudowałam czystą, nowoczesną i łatwą w nawigacji konstrukcję.

Mając wolną rękę, skupiłam się na tym, co najważniejsze dla klienta firmy budowlanej:

• Czytelna oferta – jasny zakres usług, bez marketingowego żargonu.
• Dowody w postaci zdjęć – galeria realizacji jako centralny punkt strony. W tej branży jedno zdjęcie mówi więcej niż tysiąc słów.
• Łatwy kontakt – prosty, widoczny formularz, który zachęca do zadania pytania.

Całość ubrałam w minimalistyczny, ale solidny design, pasujący do charakteru branży.

Efekt

Po zakończeniu prac przyszedł moment prezentacji – zawsze chwila lekkiego napięcia. Czy moja wizja pokryje się z oczekiwaniami? Czy dobrze odczytałam potrzeby, o których klient sam głośno nie mówił?

Jego reakcja przerosła moje najśmielsze oczekiwania. Po obejrzeniu strony podsumował projekt jednym zdaniem, które jest dla mnie największym możliwym komplementem:

„Moja strona jest lepsza od Twojej”.

W tym jednym zdaniu zawarło się wszystko: pełna akceptacja, satysfakcja i poczucie, że strona jest naprawdę „jego”. Dowód, że udało się trafić idealnie w gust i potrzeby klienta.

Dla mnie ten projekt to historia o tym, że największą satysfakcję daje nie samo kodowanie, ale moment, w którym widać autentyczną radość klienta. I że warto słuchać – nawet tego, co nie jest powiedziane wprost – i brać na siebie kreatywną odpowiedzialność.

Artykuł Twoja strona jest gorsza od mojej pochodzi z serwisu MultiTask Creations.

Krajowy System e-Faktur (KSeF) to jedna z największych cyfrowych rewolucji dla polskich firm. Z jednej strony krok w przyszłość, z drugiej – nowe wyzwanie: ręczne pobieranie i archiwizowanie setek faktur każdego miesiąca. Żmudne i obarczone ryzykiem błędu, który w księgowości bywa kosztowny.

Był jeszcze drugi haczyk. Integrację z KSeF oferowały gotowe programy księgowe – ale żeby z niej skorzystać, trzeba było taki program kupić i wpiąć się w cudzy ekosystem. A ten klient miał własne systemy, dopasowane pod siebie. Nie chciał przepłacać za kolejne oprogramowanie tylko po to, żeby mieć jedną funkcję. Moim zadaniem było zbudowanie integracji wprost pod jego środowisko – cichego, automatycznego „pracownika” w PHP, który cyklicznie łączy się z KSeF i archiwizuje dokumenty tam, gdzie firma naprawdę ich potrzebuje.

Co zrobiłam

Najciekawszym problemem nie była sama komunikacja z API, ale elastyczność. Narzędzie musiało działać dla różnych konfiguracji: jedne firmy wolą prostszy token API, inne bezpieczniejszą pieczęć elektroniczną (certyfikat .p12).

Zamiast pisać dwa osobne programy albo gmatwać się w logice warunkowej, sięgnęłam po elegancki wzorzec projektowy – Fabrykę (Factory Pattern). Jedna inteligentna „fabryka” czyta plik konfiguracyjny i sama „produkuje” idealnie skonfigurowanego klienta API – z tokenem albo z certyfikatem. Kod jest czysty, a dodanie kolejnej metody uwierzytelniania w przyszłości będzie banalnie proste.

Całość oparłam o nowoczesny stos PHP 8.1+, z Composerem i biblioteką n1ebieski/ksef-php-client jako fundamentem komunikacji:

use N1ebieskiKSEFClientResourcesClientResource;
use N1ebieskiKSEFClientClientBuilder;

function createKsefClient(string $nip): ClientResource
{
    $clientBuilder = (new ClientBuilder())
        ->withMode($mode)
        ->withNIP($nip);
    // Fabryka sprawdza wybraną metodę uwierzytelniania
    $authType = strtolower($_ENV['KSEF_AUTH_TYPE'] ?? 'token');
    if ($authType === 'certificate') {
        $clientBuilder->withCertificatePath(
            $_ENV['PATH_TO_CERTIFICATE'],
            $_ENV['CERTIFICATE_PASSPHRASE']
        );
    } else {
        $clientBuilder->withApiToken($_ENV['KSEF_TOKEN']);
    }
    return $clientBuilder->build();
}

Efekt

Stresujący obowiązek zamienił się w niewidoczny, automatyczny proces. Zamiast godzin ręcznego pobierania faktur – pewność, że wszystkie dokumenty są archiwizowane na czas, bezbłędnie i w firmowych systemach, a nie w cudzym programie. System gwarantuje 100% kompletności danych, co jest bezcenne dla księgowości i raportów.

Najważniejsze: firma nie musiała kupować kolejnego oprogramowania tylko po to, żeby spełnić jeden wymóg. Dostała integrację skrojoną pod swoje środowisko – tańszą w utrzymaniu i w pełni pod jej kontrolą. Bo czasem najlepsze rozwiązanie to nie kolejny gotowy program, ale narzędzie dopasowane dokładnie do tego, co już masz.

Artykuł Jak oswoić KSeF? pochodzi z serwisu MultiTask Creations.

Wyobraźmy sobie analityka giełdowego i jego najcenniejsze narzędzie – autorską metodę analizy spółek, dopracowywaną latami. A teraz wyobraźmy sobie, że ta metoda jest uwięziona w kilkudziesięciu osobnych plikach Excela. Każda aktualizacja notowań to godziny żmudnej, ręcznej pracy: otwórz plik, pobierz dane, wklej, sprawdź, zamknij. I tak kilkadziesiąt razy.

Taka była rzeczywistość mojego klienta. Genialny system analityczny tonął w morzu nieefektywności. Czas, który powinien iść na analizę i decyzje, uciekał na walkę z arkuszami – z ryzykiem kosztownych pomyłek. Moim zadaniem nie było napisanie kolejnego makra, ale przeprojektowanie całego procesu od podstaw.

Co zrobiłam

Architektura: od chaosu do ekosystemu. Dziesiątki plików-wysp nie potrafiły ze sobą rozmawiać. Zbudowałam zintegrowany ekosystem „master-slave”: jeden plik-matka jako centrum dowodzenia (zarządza całym portfelem, operacje hurtowe, kluczowe dane w jednym miejscu) i pliki-córki – każda spółka ma swój plik analityczny, przebudowany i podłączony do matki. Zamiast otwierać dziesiątki plików, klient zarządza wszystkim z jednego panelu.

Inteligentna aktualizacja. Zamiast za każdym razem ściągać pełną, wieloletnią historię notowań, każdy plik-córka najpierw sprawdza, jaka jest ostatnia data w arkuszu, łączy się ze źródłem (Stooq.pl) i pobiera tylko brakujące dane – od następnego dnia do dziś. Proste, ale genialne: czas aktualizacji jednego pliku spadł z minut do sekund.

Sub AktualizujDane_Stooq()
    ' Inteligentna aktualizacja danych ze Stooq.pl
    Dim symbol As String, wsDane As Worksheet, ostatniWiersz As Long
    Dim dataOd As String, dataDo As String
    Set wsDane = ThisWorkbook.Worksheets("Dane")
    symbol = ThisWorkbook.Worksheets("Panel").Range("Symbol_Spolki").Value
    ostatniWiersz = wsDane.Cells(wsDane.Rows.Count, "A").End(xlUp).Row
    If ostatniWiersz < 2 Then ' arkusz pusty -> pobierz 10 lat
        dataOd = Format(DateAdd("yyyy", -10, Date), "yyyymmdd")
    Else ' są dane -> pobierz tylko od ostatniego dnia
        dataOd = Format(wsDane.Cells(ostatniWiersz, "A").Value + 1, "yyyymmdd")
    End If
    dataDo = Format(Date, "yyyymmdd")
    PobierzIDopiszNoweDane symbol, dataOd, dataDo, wsDane
End Sub

Efekt

Proces, który potrafił zająć kilka godzin, sprowadza się teraz do kilku minut i dwóch kliknięć. Ryzyko błędu przy kopiowaniu – wyeliminowane. Ale najważniejszy efekt jest ludzki: klient odzyskał swój najcenniejszy zasób – czas. Może go poświęcić na to, co jest istotą jego pracy: analizę i świadome decyzje. Przestał być niewolnikiem narzędzia – teraz narzędzie pracuje dla niego.

Ten projekt pokazuje, że moja praca to nie pisanie pojedynczych skryptów, ale projektowanie systemów, które realnie zmieniają sposób pracy. Nawet w tak powszechnym narzędziu jak Excel drzemie moc do budowania zaawansowanych aplikacji biznesowych.

Post scriptum: bo świat się zmienia

Stan na 6 lipca 2026.

Jakiś czas po wdrożeniu Stooq zmienił sposób autoryzacji swojego API – i część pobierania danych przestała działać. To zupełnie normalne: zewnętrzne serwisy się zmieniają, a każda aplikacja, która z nich korzysta, prędzej czy później wymaga drobnej korekty. Trzeba było przepisać fragment odpowiedzialny za łączenie ze źródłem i dopasować go do nowych zasad.

Dobrze o tym pamiętać, planując własne narzędzie: to nie jest jednorazowy strzał, tylko coś, co żyje razem ze światem wokół. Właśnie po to jest utrzymanie – żeby taka zmiana była kwestią krótkiej poprawki, a nie powrotu do ręcznej roboty.

Artykuł Odzyskać czas analityka pochodzi z serwisu MultiTask Creations.

Każdy, kto próbował zmusić komputer do odczytania tekstu ze zdjęcia, wie, że OCR to często droga przez mękę. A jeśli to zdjęcie ekranu monitora? Wtedy wchodzimy na nowy poziom: odblaski, wzory moiré, nieostrość z fotografowania siatki pikseli.

W jednym z projektów miałam zbudować w Kotlinie rdzeń aplikacji mobilnej, której kluczową funkcją było precyzyjne odczytanie treści ze zrzutu ekranu. Bez solidnego „czyszczenia” obrazu cała funkcja byłaby bezużyteczna – silnik OCR zwracałby cyfrową sałatkę zamiast tekstu.

Co zrobiłam

Szybko odkryłam, że największym problemem nie są same zakłócenia, ale ich zmienność. Kluczowa okazała się różnica między trybem jasnym a ciemnym: filtry świetne dla czarnego tekstu na białym tle kompletnie zawodziły przy białym tekście na ciemnym. Jeden uniwersalny zestaw ustawień byłby kompromisem słabym w obu przypadkach. Rozwiązanie musiało być mądrzejsze – adaptacyjne.

Zamiast narzucać jedno rozwiązanie siłą, nauczyłam kod najpierw analizować problem. Funkcja sprawdza średnią jasność obrazu i na tej podstawie rozpoznaje tryb jasny albo ciemny. Dopiero wtedy dobiera zupełnie inny zestaw narzędzi z OpenCV – inny tryb progowania i inne wartości usuwania szumu. Jak lekarz, który najpierw stawia diagnozę, a potem dobiera leki:

fun preprocessForTesseract(srcMat: Mat): Mat? {
    try {
        val grayMat = Mat()
        Imgproc.cvtColor(srcMat, grayMat, Imgproc.COLOR_BGR2GRAY)
        // Kluczowy krok: średnia jasność obrazu wykrywa tryb
        val avgBrightness = Core.mean(grayMat).`val`[0]
        val isDarkBackground = avgBrightness < 100 // próg dla dark mode
        val thresholded = Mat()
        Imgproc.adaptiveThreshold(
            grayMat, thresholded, 255.0,
            Imgproc.ADAPTIVE_THRESH_MEAN_C,
            // dla ciemnego tła odwracam działanie filtra
            if (isDarkBackground) Imgproc.THRESH_BINARY_INV else Imgproc.THRESH_BINARY,
            if (isDarkBackground) 31 else 45,
            if (isDarkBackground) 11.0 else 15.0
        )
        grayMat.release()
        return thresholded
    } catch (e: Exception) { return null }
}

Efekt

Adaptacyjna logika przyniosła natychmiastowe efekty. Dokładność OCR wzrosła diametralnie – aplikacja radziła sobie równie dobrze ze zdjęciem Notatnika w Windowsie, jak i z terminalem programisty na ciemnym tle. Zawodna funkcja stała się stabilnym, godnym zaufania komponentem – fundamentem, na którym można było spokojnie rozwijać całą aplikację.

Uwielbiam takie wyzwania, bo w programowaniu diabeł tkwi w szczegółach. Zamiast szukać drogi na skróty, wolę zrozumieć problem do końca i zbudować rozwiązanie, które sprawdzi się w realnym świecie.

To jedna strona projektu aplikacji OCR. O drugiej – skrypcie w Pythonie, który zasilał jej bazę danych – pisałam tutaj.

Artykuł Ten sam kod, dwa różne światy pochodzi z serwisu MultiTask Creations.

Nowy, ekscytujący projekt: skrypt zasilający bazę danych aplikacji mobilnej OCR. Jeden problem – całe „złoto”, które ma tę bazę wypełnić, jest zamknięte w setkach stron plików PDF.

Był wybór. Droga na skróty: otworzyć każdy PDF i ręcznie przekopiować setki pytań i odpowiedzi. Wykonalne, ale piekielnie żmudne, powolne i proszące się o błąd – zwłaszcza że klient planował dosyłać kolejne pliki. Wybrałam drugą drogę, tę którą uwielbiam: zamiast godzin klikania, napisać prosty, ale potężny konwerter w Pythonie, który zrobi to za mnie.

Co zrobiłam

Pierwszy krok – wyciągnięcie surowego tekstu z PDF-ów biblioteką pdfplumber – poszedł gładko. Prawdziwe wyzwanie zaczęło się później: każdy PDF, choć z pozoru identyczny, miał swoje „widzimisię” – a to dodatkowy odstęp, a to inny znak nowej linii. Proste metody oddzielania pytań od odpowiedzi zawodziły.

Tu wchodzi moja tajna broń: wyrażenia regularne (RegEx). To jak dać komputerowi supermoc rozumienia wzorców. Zamiast „szukaj litery A”, mówię: „znajdź linijkę zaczynającą się od A, po której może być gwiazdka, potem spacja, a potem przechwyć wszystko do końca linii”. Dzięki bibliotece re zbudowałam precyzyjne wzorce, które wyłuskiwały z chaosu dokładnie te dane:

# Fragment kodu, który z bloku tekstu wyciąga pytanie i odpowiedź
for i in range(1, len(blocks), 2):
    content = blocks[i + 1].strip()
    # RegEx znajduje poprawną odpowiedź (zaczynającą się od 'A')
    match = re.search(r'^A*?s*(.+)', content, re.MULTILINE)
    if match:
        correct_answer = match.group(1).strip()
        question_text = re.split(r'^A*?s*(.+)', content, maxsplit=1, flags=re.MULTILINE)[0].strip()
        questions.append({
            "questionText": question_text,
            "correctAnswerText": correct_answer
        })

Na końcu skrypt zapisywał wszystko w czystym, ustrukturyzowanym pliku JSON – gotowym do zasilenia bazy aplikacji.

Efekt

Proces, który ręcznie zająłby wiele dni żmudnego kopiowania, skrócił się do kilku minut. Co ważniejsze – powstało rozwiązanie skalowalne: gdy klient przyśle nową partię PDF-ów, aktualizacja bazy będzie błyskawiczna i bezbłędna.

Uwielbiam takie projekty, bo pokazują prawdziwą moc kodu. To nie była budowa wielkiego systemu, ale małe, proste narzędzie, które rozwiązało jeden, za to bardzo uciążliwy problem. Czasem taki sprytny skrypt daje więcej niż największa aplikacja – uwalnia od nudy i zostawia czas na kreatywną pracę.

Ten skrypt to jedna strona projektu aplikacji OCR. O drugiej – algorytmie, który radził sobie z trybem jasnym i ciemnym – pisałam osobno tutaj.

Artykuł Zamiast klikać, napisałam kod pochodzi z serwisu MultiTask Creations.

Jest taki moment w każdym projekcie – ten, w którym 95% pracy jest już za sobą. Efekt widać, jest z czego być dumnym, ale kilka upartych, technicznych problemów stoi na drodze do mety. I właśnie te ostatnie metry okazują się najtrudniejsze.

Tak zaczęła się współpraca z bardzo zdolną klientką, która samodzielnie zbudowała fundamenty swojego sklepu. Ogrom pracy – ale przed wielkim otwarciem natrafiła na kilka przeszkód, przy których potrzebowała wsparcia. Moim zadaniem było wypolerować ten diament.

Co zrobiłam

Przeszkoda 1: zapomniane „drzwi na klucz”. W konfiguracji sklepu wciąż aktywna była opcja „Strona w budowie”, widoczna dla każdego niezalogowanego gościa. Klasyczna blokada startowa – szybka diagnoza i jedno kliknięcie otworzyły drzwi klientom.

Przeszkoda 2: pierwsze wrażenie. Dodałam boczne menu ułatwiające przeglądanie kategorii i poprawiłam widoczność wyszukiwarki na telefonach. Drobne szlify, które decydują, czy klient znajdzie to, czego szuka – czy zniechęci się i wyjdzie.

Przeszkoda 3: logika ścieżki powrotu (breadcrumbs). Najtrudniejsza. Gdy produkt należał do dwóch kategorii, ścieżka powrotu zawsze pokazywała domyślną – ignorując to, skąd użytkownik faktycznie przyszedł. Jakby ktoś wchodzący do działu z butami był odsyłany do działu z czapkami. Standardowe wtyczki nie dawały rady – trzeba było zajrzeć „pod maskę” i napisać własny kod, który inteligentnie śledzi ścieżkę:

// Kluczowy fragment kodu dodany do functions.php
// Sprawdza, czy użytkownik wszedł na stronę produktu z konkretnej podkategorii.
$force_subcat = isset($_GET['force_subcat'])
    ? sanitize_text_field($_GET['force_subcat'])
    : '';
if ($force_subcat) {
    // pobieram informacje o tej kategorii i dynamicznie
    // modyfikuję „okruszki", by pokazywały poprawną ścieżkę.
}

Efekt

Ten kod był ostatnim elementem układanki. Po wdrożeniu bariery zniknęły, a sklep był wreszcie gotowy na pierwszych klientów. W takich projektach największą satysfakcję daje właśnie ten moment przełamania – pomoc innym twórcom w pokonaniu technicznych przeszkód, które dzielą ich od pokazania swojej wizji światu.

Artykuł Polerowanie diamentu pochodzi z serwisu MultiTask Creations.