Artykuly

Poproś model o odpowiedź w JSON i w większości przypadków json.loads() działa bez problemu. Problemy zaczynają się tam, gdzie kosztują cię sesję debugowania: jednoliniowy komentarz w środku obiektu, markdown code fence owijający całość, klucz zapisany jako userEmail, gdy kod oczekuje user_email. Bardziej rygorystyczny prompt (“odpowiedz WYŁĄCZNIE obiektem JSON, bez żadnego innego tekstu”) sprawia, że takie przypadki są rzadsze. Nie eliminuje ich całkowicie, bo model nadal może zignorować prośbę. Ustrukturyzowane wyjście usuwa prośbę z równania: przekazujesz API JSON Schema, który ogranicza samplowanie tokenów samego modelu tak, że odpowiedź musi do niego pasować. ...

Piszesz .sidebar .card { color: blue; }, ładujesz stronę, a karta jest wciąż czerwona przez regułę dodaną godzinę wcześniej: .card { color: red; }. Nowa reguła jest niżej w pliku. I mimo to przegrywa. Przeglądarka porównuje dwa selektory przy użyciu stałego systemu punktowego, a .sidebar .card dostaje wyższy wynik niż .card, niezależnie od tego, który napisano później. Ten system punktowy to specyficzność. Kiedy już umiesz ją liczyć od razu, “czemu mój CSS się nie stosuje” staje się arytmetyką. Nie ma to nic wspólnego z layoutem: Grid czy Flexbox decyduje, gdzie znajduje się element, a specyficzność decyduje, która reguła ustawia jego kolor albo rozmiar, gdy dwie reguły są w konflikcie. ...

Wyszukanie klucza w Pythonowym dict z dziesięcioma wpisami zajmuje tyle samo czasu, co w dict z dziesięcioma milionami. To nie wynika z szybkości języka. Pythonowy dict, Javowy HashMap i Map w JavaScript to wszystko tabele haszujące, a cały ten projekt istnieje po to, by wyszukiwanie, wstawianie i usuwanie działały średnio w O(1). Notacja Big O nazywa to wyszukiwanie “czasem stałym”. Oto mechanizm, który na to zasługuje. Jak tabela haszująca zmienia klucz w indeks tablicy Tabela haszująca to tablica plus funkcja, która zmienia klucz w pozycję w tej tablicy. ...

Program w C, który zwalnia bufor i dalej z niego czyta, mimo to się kompiluje. Potem psuje pamięć, czasem natychmiast, czasem trzy requesty później, w fragmencie kodu, który nigdy tego bufora nie dotknął. Rust odrzuca taki program już na etapie cargo build, i nie ma w tym żadnego garbage collectora. Kompilator śledzi, kto jest właścicielem każdej wartości i kto może na nią patrzeć. To śledzenie to właśnie ownership i borrowing. ...

Test dla place_order potrzebuje bramki płatności, klienta SMS i kalkulatora podatku. Podłącz prawdziwe zależności i każde uruchomienie testu obciąży kartę i wyśle SMS na prawdziwy numer. Test jednostkowy ma działać w milisekundach, bez sieci, więc wszystkie trzy trzeba czymś zastąpić. To “coś innego” ma pięć odmian, każda rozwiązuje inny problem, a traktowanie ich jako wymienne jest powodem, dla którego spory “po prostu zmockuj to” w code review nie mają końca. ...

Zapisujesz plik, Prettier go formatuje, a ESLint natychmiast zgłasza błąd w linii, którą Prettier właśnie dotknął. Oba narzędzia są skonfigurowane, oba działają — i zamiast pomagać, walczą ze sobą. Te dwa narzędzia robią różne rzeczy. Problem w tym, że oba mają zdanie na temat jednej sprawy: jak kod ma wyglądać na ekranie. Co ESLint faktycznie sprawdza ESLint rozkłada kod na abstrakcyjne drzewo składniowe i uruchamia reguły na jego strukturze. Największa wartość pochodzi z reguł, które wyłapują realne bugi: zmienną, która nigdy nie została zdefiniowana, nieosiągalny return po innym return, nieużywany import, który został po refaktoryzacji, zduplikowany klucz w obiekcie, który bez ostrzeżenia nadpisuje pierwszy. To kontrole semantyczne — ESLint czyta, co kod robi. ...

Dlaczego przelew bankowy wymaga więcej niż dwóch UPDATE Przenieś 50 zł z jednego konta na drugie, a naiwna wersja to dwie instrukcje: odejmij od konta A, dodaj do konta B. Wykonaj je osobno, a jeśli proces padnie albo połączenie się zerwie między tymi dwoma, pieniądze znikają z A i nigdy nie docierają do B. Baza danych zrobiła dokładnie to, o co ją poproszono, dwa razy. Biznes i tak stracił 50 zł. ...

Czemu “wygląda dobrze” nie jest testem dla prompta Dopracowujesz treść prompta, który klasyfikuje zgłoszenia, sprawdzasz go na trzech przykładach otwartych w notatniku i wdrażasz. Tydzień później reklamacje dotyczące rozliczeń, które wcześniej trafiały do właściwej kolejki, zaczynają trafiać do “pytania”. Nie te trzy przypadki, które sprawdziłeś, ale te pozostałe czterysta, których nie sprawdziłeś. Nic się nie wywala. Nie ma żadnego stack trace’u. Prompt przeczytany na głos wciąż brzmi dobrze. Code review i kilka ręcznych sprawdzeń tego nie wychwytuje, bo ten sam prompt na tym samym wejściu nie zwraca dwa razy tego samego tekstu. Nie możesz porównać dwóch przebiegów bit po bicie i nazwać różnicę bugiem, tak jak przy czystej funkcji. Co możesz sprawdzić, to czy każda odpowiedź ma właściwości, na których ci zależy: właściwą kategorię, podsumowanie poniżej limitu długości, żadnego pola, którego źródło nigdy nie wspominało. Eval uruchamia te sprawdzenia na zbiorze prawdziwych danych wejściowych przy każdej zmianie prompta albo modelu, więc regresja wychodzi na jaw w twoim terminalu, a nie w zgłoszeniu klienta. ...

Komponent czatu łączy się ponownie przez WebSocket za każdym razem, gdy wpisujesz literę w polu wyszukiwania, które nie ma nic wspólnego z czatem. Inny komponent renderuje się w kółko, aż karta się zawiesza. Trzeci wywołuje swój useEffect dwa razy przy montowaniu, ale tylko w trybie deweloperskim. Żaden z tych przypadków nie jest błędem Reacta. Dwa pierwsze to tablica zależności robiąca dokładnie to, co jej kazano, a trzeci to Strict Mode sprawdzający, czy twój efekt umie się po sobie posprzątać. ...

<.+> dla <b>bold</b> and <i>italic</i> nie znajduje <b>. Znajduje cały ciąg, od pierwszego < do samego ostatniego >. Nic nie jest zepsute. To właśnie ma robić zachłanny (greedy) kwantyfikator, i to jest też najczęstszy błąd typu “regex matchuje zbyt dużo”. Gdy już wiesz, co silnik robi podczas czytania wzorca, ten błąd i większość jego krewnych przestają być zagadką. Jak silnik regex czyta twój wzorzec Silnik regex nie porównuje wzorca z ciągiem tak, jak porównuje się dwa ciągi pod kątem równości. Silniki, które używasz codziennie (re w Pythonie, RegExp w JavaScript, PCRE, .NET, Java) są regex-directed: przechodzą przez wzorzec od lewej do prawej, token po tokenie, i dla każdego tokenu próbują skonsumować znaki z ciągu w aktualnej pozycji. Gdy token się dopasuje, silnik przesuwa wskaźnik wzorca i wskaźnik ciągu. Gdy token zawodzi, silnik robi backtracking: wraca do ostatniego miejsca, w którym miał wybór, na przykład kwantyfikator, który mógł dopasować mniej znaków, albo gałąź alternatywy, której jeszcze nie spróbował, i wybiera drugą opcję. ...