Wyniki ostatniej ankiety State of CSS są już dostępne.

Jeśli interesują Cię obecne trendy i stopień adaptacji nowych funkcji, to zdecydowanie warto tam zajrzeć.

Pełny raport znajdziesz tutaj: https://2025.stateofcss.com/en-US/

Luka pomiędzy tym, co zostało "powiedziane", a tym, co zostało "usłyszane", jest miejscem, w którym rodzą się kosztowne nieporozumienia.

Różnica ta jest jeszcze bardziej widoczna w zespołach rozproszonych po całym świecie. Kiedy mieszają się różne kultury, style komunikacji i zwyczaje, potencjał do błędnej interpretacji rośnie wykładniczo.

Niektóre kultury cenią sobie bezpośrednią, jasną komunikację, podczas gdy inne w dużej mierze polegają na czytaniu między wierszami. Sprawdza się to dobrze, gdy wszyscy dzielą ten sam kontekst kulturowy, ale w globalnym zespole jest to przepis na chaos. Istnieje wysokie prawdopodobieństwo, że jeśli nie wyrazisz czegoś wprost, Twój kolega lub koleżanka z innej części świata nie zrozumie intencji.

Dlaczego? Ponieważ nie jest on wyczulony na niuanse Twojej kultury. Nie zrozumie, że zdanie: “To będzie spore wyzwanie”, może w rzeczywistości oznaczać: “Ten termin jest niemożliwy do dotrzymania i musimy przemyśleć plan na nowo”.

Aby zniwelować tę przepaść, najskuteczniejszym krokiem jest ustanowienie prostej zasady: mów wprost. Promuj kulturę zespołową, w której każdy mówi to, co ma na myśli, nie pozostawiając kluczowych informacji między wierszami i w sferze domysłów.

Kluczowe jest, aby odpowiednio tę zasadę przedstawić. Musi być jasne, że bezpośredniość nie jest atakiem ani obrazą, a raczej sposobem na eliminowania niejasności. Gdy osoba z kultury o bardzo bezpośredniej komunikacji (np. holenderskiej) wchodzi w interakcję z kimś z kultury bardziej pośredniej (np. japońskiej), styl tej pierwszej może być postrzegany jako agresywny. Ustanawiając jawną normę zespołową, tworzysz wspólne zrozumienie, że to właśnie klarowność jest celem.

Ta zmiana nie nastąpi z dnia na dzień. Zastąpienie uwarunkowań kulturowych nabywanych przez całe życie wymaga czasu i świadomego wysiłku. I chociaż bezpośrednia komunikacja nie jest złotym środkiem na każde wyzwanie projektowe, stanowi fundamentalny krok w kierunku budowania bardziej spójnego i efektywnego globalnego zespołu.

Więcej na ten temat znajdziesz w książce Mapa Kulturowa.

Od kilku dni mamy możliwość wypełnienia ankiety State of HTML 2025.

Udział w niej, to świetna okazja, żeby wyrazić swoje zdanie w temaice standardów webowych. Przy okazji, jest to również dobry sposób na sprawdzenie własnej wiedzy, poznanie aktualnych trendów i uzupełnienie ewentualnych braków w znajomości najnowszych zagadanień.

Ankietę znajdziesz tutaj: https://survey.devographics.com/en-US/survey/state-of-html/2025

Konstrukcja try...catch...finally jest kluczowa w obsłudze błędów w JavaScript. Kryje jednak w sobie subtelną pułapkę, która może prowadzić do wyjątkowo mylących błędów.

W czym konkretnie tkwi problem? W umieszczeniu instrukcji return lub throw wewnątrz bloku finally.

Użycie ich w tym miejscu nadpisze każdą instrukcję return oraz throw z bloków try i catch. Może to prowadzić do niezwykle mylącego zachowania i trudnych do zlokalizowania błędów. Taki kod jest szczególnie niebezpieczny, gdy nie pracujemy sami – inni członkowie zespołu mogą spędzić długie godziny na debugowaniu, jeśli nie są zaznajomieni z tą specyficzną właściwością.

Wniosek? Należy unikać umieszczania return lub throw w bloku finally. Jeśli czujesz taką potrzebę, może to być oznaką większego problemu z architekturą Twojego kodu. W rzadkich przypadkach, gdy masz ku temu konkretny powód, dodaj czytelny komentarz, aby oszczędzić zespołowi przyszłych problemów.

Kilka dni temu Amazon przedstawił swoje nowe IDE - Kiro. Dodał przy tym, że jest to rewolucja. Czy faktycznie nią jest?

Pod spodem napędza je model Claude Sonnet. To Rodzi natychmiastowe pytanie: co odróżnia to narzędzie od istniejącego od jakiegoś czasu agenta Claude Code?

Amazon twierdzi, że jest to przede wszystkim podejście, które określa jako „spec-driven development”. Idea polega na prowadzeniu agenta poprzez tworzenie plików markdown, które opisują projekt, wymagania i zadania. Jeśli ten proces brzmi znajomo, to dlatego, że bardzo przypomina przepływ pracy, który wielu programistów już stosuje, korzystając z istniejących asystentów AI.

Kiro jest zatem kolejnym forkiem Visual Studio Code o zamkniętym kodzie źródłowym, który obiecuje rewolucję w sposobie tworzenia oprogramowania. Jednak jego podstawowa metodologia nie wydaje się być zupełnie nowym paradygmatem, a raczej rozwinięciem tego, co oferują nam istniejące narzędzia. Powiedziałbym raczej, że to ewolucja, a nie rewolucja.

Nie zmienia to faktu, że początkowe zainteresowanie było tak duże, że Amazon wstrzymał możliwość pobierania i wprowadził listę oczekujących.

Oficjalną stronę projektu oraz wspomnianą listę, znajdziesz tutaj: https://kiro.dev/