Czemu any odbiera przekazany typ? Otypuj parametr jako any i TypeScript przestaje sprawdzać wszystko, co wychodzi z funkcji: 1 2 3 4 5 6 function firstElement(arr: any[]): any { return arr[0]; } const n = firstElement([1, 2, 3]); n.toUpperCase(); // kompiluje się, wywala w czasie działania Ty wiesz, że przekazałeś tablicę liczb. Kompilator nie wie, bo any mówi mu, żeby przestał patrzeć. n wraca jako any, więc wywołanie metody string na liczbie kompiluje się bez problemu i wyrzuca TypeError: n.toUpperCase is not a function przy uruchomieniu. ...

Otwórz w Python plik, który nie istnieje, i open() zgłasza FileNotFoundError, który wychodzi poza twoją funkcję. Zrób to samo w Go, a os.ReadFile zwraca wartość error razem z nilowym slice’em bajtów. Ten sam błąd, dwie zupełnie inne formy kodu wokół niego. Różnica nie jest kosmetyczna. Decyduje o tym, czy wywołujący może przypadkowo zignorować błąd, i czy kompilator to zauważy, gdy to się stanie. Co exceptions i wartości błędów robią naprawdę inaczej? Exception to przepływ sterowania, który skacze. Coś zawodzi, funkcja zgłasza wyjątek, a wykonanie opuszcza bieżący stos wywołań i trafia do najbliższego dopasowanego bloku catch albo except, niezależnie od tego, ile poziomów wyżej to jest. Sygnatura funkcji nie daje żadnej wskazówki, że to może się zdarzyć. loadConfig(path: string): Config w TypeScript wygląda jak funkcja, która nie może zawieść — aż zgłosi wyjątek przy brakującym pliku. ...

Jesteś w trakcie zmian w trzech plikach na feature branchu, nic jeszcze nie zacommitowane, gdy kolega pisze o null-pointerze, który wywala produkcję. Standardowy ruch to git stash, checkout na main, poprawka, push, a potem git stash pop w nadziei, że nic w twojej niedokończonej funkcjonalności nie zależało od plików, od których właśnie odszedłeś. git worktree pomija całą tę żonglerkę. Robi checkout brancha z hotfixem do drugiego folderu, obok twojego feature brancha, a oba korzystają z tego samego repozytorium. ...

Jeden klient zapętlony w retry loop bez backoffu może w jedną minutę wygenerować na twoim API więcej obciążenia niż pozostałe dziesięć tysięcy klientów razem wzięte. Z twojej strony to nie wygląda jak atak. Wygląda jak bug u nich, a staje się incydentem u ciebie. Rate limiter zatrzymuje tego klienta, zanim do tego dojdzie. Co właściwie decyduje rate limiter? Przy każdym requeście limiter zadaje sobie jedno pytanie: czy ten klucz wykonał w bieżącym oknie czasowym za dużo requestów? Trzy decyzje zmieniają to w coś, co można zaimplementować. ...

Co function calling naprawdę robi w LLM Zapytaj model “jaka jest teraz pogoda w Austin” bez żadnego połączenia ze światem zewnętrznym, a masz dwie opcje: powie, że nie wie, albo coś zmyśli. Function calling daje mu trzecią opcję. Model opisuje, czego potrzebuje, przekazuje ten opis twojemu kodowi i czeka na prawdziwą odpowiedź, zanim sam odpowie. Nazwa jest trochę myląca. Model niczego nie wywołuje. Zwraca blok ustrukturyzowanych danych mówiący, jaki tool chce użyć i z jakimi argumentami, a twoja aplikacja decyduje, czy go uruchomić i co zrobić z wynikiem. “Tool use” to dokładniejszy termin, ten używany w dokumentacji Anthropic; OpenAI i Google zwykle mówią function calling. Mechanizm jest ten sam pod obiema nazwami. Model tworzy tylko żądanie, nigdy sam efekt. ...

Listener scroll na window może odpalać się setki razy podczas jednego przesunięcia ekranu. Jeśli przy każdym takim evencie wywołujesz getBoundingClientRect() na każdej karcie w feedzie, pięćdziesiąt obrazów wystarczy, żeby strona zaczęła się zacinać. Intersection Observer API zdejmuje to sprawdzenie ze ścieżki scrolla: rejestrujesz, jakie elementy obserwować, a przeglądarka informuje cię, gdy ich widoczność naprawdę się zmienia. Jak działa IntersectionObserver Observer obserwuje jeden lub więcej elementów target względem root (domyślnie viewport) i wywołuje callback, gdy target przekroczy próg widoczności. ...

Otwórz plik zapisany w UTF-8 w narzędziu, które zakłada inne kodowanie, i café zmienia się w café. Bajty na dysku się nie zmieniły. Zmieniła się tylko reguła odczytu, czyli sposób zamiany bajtów z powrotem na znaki, a te dwie reguły różnie rozumieją, co znaczy bajt 0xC3. Większość błędów z “dziwnymi znakami” ma to samo źródło: połamane nazwy plików, zmasakrowane formularze, emoji, które wywala insert do bazy danych, dwa stringi wyglądające identycznie, ale różne w porównaniu. Za każdym z nich stoi ta sama pomyłka: mylenie Unicode z UTF-8, dwóch zupełnie różnych rzeczy. ...

Co to jest closure w JavaScript? 1 2 3 4 5 6 7 8 9 10 11 12 function makeCounter() { let count = 0; return function () { count += 1; return count; }; } const counter = makeCounter(); console.log(counter()); // 1 console.log(counter()); // 2 console.log(counter()); // 3 makeCounter działa raz, zwraca funkcję i na tym koniec: jej stack frame już nie istnieje. Mimo to każde wywołanie counter() wciąż odczytuje i aktualizuje count — zmienną zadeklarowaną wewnątrz funkcji, która już się zakończyła. count nie wraca do 0 i nie jest kopiowana. To wciąż ta sama zmienna, żywa, trzy wywołania później. ...

Test napisany po kodzie zwykle sprawdza to, co kod robi, a nie to, co miał robić. Programowanie sterowane testami (TDD) naprawia to, odwracając kolejność: piszesz test, patrzysz, jak nie przechodzi, a potem piszesz najmniejszy możliwy kod, który sprawia, że test przechodzi. Ponieważ test istnieje przed kodem, który sprawdza, nie może po cichu uznać za poprawne tego, co akurat zwróci kod. Kent Beck sformalizował ten cykl jako red, green, refactor w swojej książce z 2002 roku Test-Driven Development: By Example. Nazwa się przyjęła. ...

Odpal npm install w projekcie, a potem pnpm install na tym samym package.json – dostajesz dwa różne drzewa node_modules i dwa różne lockfile’y. Dodaj kolegę, który sięga po Yarn, i w historii repozytorium lądują trzy lockfile’y, każdy opisujący nieco inne drzewo zależności. Wszystkie trzy czytają ten sam package.json i pobierają z tego samego rejestru npm. Nie zgadzają się co do tego, co zapisać na dysku. Jak npm, Yarn i pnpm układają node_modules Struktura npm jest płaska. Każdy pakiet, którego potrzebują twoje zależności, niezależnie od tego, jak głęboko w drzewie, trafia do głównego node_modules, jeśli nie ma konfliktu wersji. To domyślne zachowanie od npm 3. Efekt uboczny: twój kod może zrobić require() albo import pakietu, którego nigdy nie wpisałeś do package.json, o ile cokolwiek innego w drzewie od niego zależy. Działa to, dopóki ten inny pakiet nie usunie tej zależności w minor release – wtedy twój build się psuje, mimo że w twoim kodzie nic się nie zmieniło. To jest phantom dependency, a struktura npm nic z tym nie robi. ...