W programistycznej karierze przychodzi w końcu taki moment, w którym musimy zmierzyć się z wyjątkowo trudnym do zdiagnozowania błędem. Moją piętą achillesową okazał się bug, z którym walczyłem półtora tygodnia i poległem; dopiero moi koledzy, którzy zaczęli mozolnie komentować duże partie kodu, dotarli do źródła problemu. W niniejszym artykule przedstawię zbiór mniej lub bardziej zaawansowanych i niekonwencjonalnych technik debugowania.

W tym artykule przyjrzymy się kilku mechanizmom .NET MAUI, które mogą przydać się w bardziej rozwiniętych projektach. Przykładowe programy, których użyję do ich przedstawienia, nie będą zbyt efektowne – można je wręcz nazwać banalnymi – moim celem jest jednak skupienie się na samych omawianych elementach i na tym, żeby łatwo było je zrozumieć, bez rozbudowanych przykładów, które mogłyby zagmatwać przekaz.

Generowanie metryk kodu jest jednym z najprostszych zautomatyzowanych sposobów weryfikacji jakości kodu źródłowego. Statystyki numeryczne mają tę prostą zaletę, że śledząc konkretne wartości, możemy łatwo wskazać na poprawę lub pogorszenie określonego parametru. Na rynku istnieją gotowe rozwiązania, przy pomocy których metryki takie możemy wygenerować, ale czasami zdarza się, że wygodniej jest zrobić to samodzielnie – tym bardziej że do dyspozycji mamy świetne biblioteki z rodziny Microsoft.CodeAnalysis, znane niegdyś jako projekt Roslyn.

Trudno sobie wyobrazić współczesny świat IT bez rozwiązań takich jak jak Docker czy Kubernetes. Od aplikacji wymaga się coraz częściej małej latencji oraz reagowania automatycznie na zwiększenie obciążenia i ruchu sieciowego. Powstające technologie ułatwiają to zadanie, ale jednocześnie wprowadzają nowe płaszczyzny do cyberataków. Odpowiedzią na te problemy jest projekt Podman. W niniejszym artykule odpowiemy sobie na kluczowe pytanie, jak narzędzie to – i w jakim zakresie – poprawia bezpieczeństwo.

Zarządzanie budowaniem projektów w C++ jest, jak wiele innych zadań w tym języku programowania, jednocześnie proste oraz dość skomplikowane. Aby uporać się z tym problemem, powstało wiele konkurencyjnych rozwiązań od twórców kompilatorów, środowisk programistycznych, frameworków oraz od innych osób. W tym artykule postaram się wstępnie przybliżyć CMake: narzędzie, które w ostatnich latach cieszy się największą popularnością, wspiera wszystkie najważniejsze systemy, kompilatory, a także miało bezpośredni wpływ na zmiany w nowych standardach języka C++.

We wrześniu br. na konferencji CppCon 2022 Herb Sutter, sekretarz komitetu standaryzacyjnego języka C++, wygłosił referat zatytułowany „Czy C++ może stać się 10 razy prostszy i bezpieczniejszy…?”, przedstawiając w nim pomysł na rozwiązanie problemów, z którymi C++ boryka się od kilkunastu lat. Chodzi tu o takie kwestie, jak stale rosnąca złożoność języka oraz brak wbudowanych mechanizmów gwarantujących bezpieczeństwo aplikacji. Czy zaproponowana idea oraz powiązany z nią eksperymentalny kompilator cppfront mogą stanowić rewolucyjny zwrot w historii języka C++? Niniejszy artykuł stanowi próbę znalezienia odpowiedzi na to pytanie.

Projektując dynamiczną aplikację webową, nie sposób uniknąć tematu przetwarzania danych podawanych przez użytkowników. W szczególności w projektach, w których wyświetlane są wprowadzone w ten sposób teksty – takich jak na przykład fora czy systemy zarządzania zgłoszeniami – powinno kłaść się szczególny nacisk na walidację i tak zwaną sanityzację wprowadzanych danych wejściowych, jak i wyjściowych. Brak takich zabezpieczeń może doprowadzić do popularnego wektora ataku – Stored XSS. Toy Workshop jest przykładem właśnie takiej aplikacji.

W systemach operacyjnych istnieją mechanizmy, które początkowo nie miały nic wspólnego z bezpieczeństwem. Z czasem jednak dostrzeżono w nich potencjał i zaproponowano bazujące na nich rozwiązania. Takim przykładem jest wywołanie systemowe chroot(2). Dziś przyjrzymy się programistycznym błędom związanym z tym wywołaniem systemowym.

Wielu programistów zastanawia się się nad następnym krokiem na ścieżce swojego rozwoju zawodowego – część chce awansować na seniora, ten i ów na menadżera, a niektórzy decydują się na stanowisko, w którego nazwie jest „architekt”. Funkcja ta bywa w branży IT dość mętnie zdefiniowana, dziedzina jest uważana za naukę tajemną, a potencjalni kandydaci często mają mgliste pojęcie o tym, czym będą się zajmować. W tym artykule chciałbym rozwiać wątpliwości i mity otaczające architekturę oprogramowania i rolę architekta.

Jeśli ktoś zna mnie choć trochę, to wie, że organicznie nie znoszę wyświechtanych frazesów. Ale po zebraniu całej masy informacji na temat tego, w jaki sposób Valve zaprojektowało swoje urządzenie, a także – gdy moja rezerwacja w końcu trafiła na początek kolejki – bazując na własnym doświadczeniu, zaiste trudno jest mi dobrać bardziej trafny podtytuł. Można powiedzieć, że firma założona przez Gabe’a Newella nie tyle wsadziła kij w mrowisko, co bardziej otworzyła pod nim portal wiodący na księżyc.

Ustawa o prawie autorskim i prawach pokrewnych co do zasady obejmuje ochroną prawno-autorską programy komputerowe, jednakże nie wprowadza ich definicji. Nie każdy program komputerowy podlega ochronie prawno-autorskiej z samego tytułu bycia programem – decydują o tym jeszcze jego inne cechy, jak m.in. twórczy charakter. Z tego powodu w praktyce ustalenie, czy program albo jego poszczególne składowe podlegają ochronie, może nastręczać trudności. Kiedy zatem program lub aplikacja podlega ochronie? Co jeśli program powstał na zlecenie firmy z innego państwa niż Polska? Jak ochronić interfejs graficzny? Czy można objąć ochroną sam algorytm lub pomysł na program czy aplikację?