Programista 6/2020 (93)
Programista 6/2020 (93)
Czy nie chcielibyśmy łatwo przenosić naszych aplikacji mikroserwisowych między środowiskiem lokalnym a różnymi chmurami? Czy nie chcielibyśmy pisać mniej kodu, skupiając się jedynie na funkcjonalnościach biznesowych zamiast na różnych elementach infrastruktury, jak np. Kafka czy Redis? Czy nie życzylibyśmy sobie automatycznego tworzenia definicji obrazów Dockera i manifestów Kubernetes, ich wdrażania oraz prostego konfigurowania różnych narzędzi, jak np. Zipkin? Część z tych problemów rozwiązuje otwarta i niezależna od języka platforma Dapr. Tye to z kolei będące w fazie rozwoju narzędzie dla samego .NET. Zobaczmy, co może nam dać połączenie Tye z Dapr.
Pulpit Windows – jeżeli się chwilę nad tym zastanowić – jest chyba najmniej użytecznym miejscem w całym systemie. Możemy tu ustawić tło, przechować skróty i pliki w postaci ikon i w zasadzie to wszystko. Odkryjmy w sobie wewnętrznego geeka i zobaczmy, jak możemy ten stan rzeczy zmienić, wykorzystując nasze umiejętności programistyczne.
W rozwoju oprogramowania testowanie odgrywa olbrzymią rolę. Nie inaczej jest w konfiguracji infrastruktury. Do najpopularniejszych narzędzi służących konfiguracji systemów możemy zaliczyć Chefa, którego testujemy frameworkiem Kitchen, Puppet z rspec’iem oraz Ansible, który od 2018 zaleca korzystanie z molecule.
Name lookup to dość specyficzny proces w języku C++. Z jednej strony tak oczywisty i podstawowy, że nawet nie zastanawiamy się, kiedy z niego korzystamy. Z drugiej zaś jest na tyle zaawansowany, że powstają różnego rodzaju zbiory zasad, jak z nich korzystać. W tym artykule przyjrzymy się temu, czym jest name lookup, jak działa i kiedy może on przysporzyć nam problemów.
„Mogę śmiało powiedzieć, że praca przy projektach telekomunikacyjnych na pewno nie jest nudna, a ze względu na swój charakter pozwala na znaczne rozszerzenie swoich umiejętności oraz daje satysfakcję wynikającą z tego, że system, który tworzymy, wpływa na życie innych ludzi” – mówi Kacper Janda, programista pracujący w obszarze R&D sektora telekomunikacja w Comarch.
Architekturę systemu uważa się za pojęcie subiektywne. Każdy projekt, niezależnie od wielkości, określa własne wymagania biznesowe, techniczne oraz budżetowe. Specyfika postawionych wymagań wyznacza ścieżkę rozwoju oprogramowania i stopień jego złożoności. Najczęściej złożoność rośnie dużo szybciej od rozmiarów systemu. Jeśli nie zadba się o to w pierwszych etapach projektu, to relatywnie szybko dojdziemy do utraty kontroli nad systemem.
W tym artykule, będącym kontynuacją tekstu opublikowanego w poprzednim numerze, odbędziemy podróż po meandrach implementacji „Gry w Życie“. W trakcie lektury dowiemy się, jak można usunąć sztywne granice przestrzeni gry oraz jak ograniczyć złożoność obliczeniową algorytmu kontrolującego symulację. Przy okazji poznamy szereg ciekawych mieszkańców tego tajemniczego, płaskiego świata, a także przybliżymy sposób działania HashLife, algorytmu, dzięki któremu można tworzyć i badać złożone struktury „Gry w Życie“ o monstrualnych wręcz rozmiarach.
Realizacja celów biznesowych w projektach badawczo-rozwojowych jest bardzo prosta, jeśli wiesz, jak prawidłowo zorganizować swoją pracę. Rozpoczynając projektowanie systemu, zmniejsz ryzyko niepowodzenia, odpowiadając na kilka ważnych pytań. Mam nadzieję, że praca badawcza stanie się dla ciebie bardziej przyjemna po lekturze tego artykułu.
Protokół HTTPS, a dokładniej HTTP over TLS, jest rozszerzeniem protokołu HTTP o funkcjonalność szyfrowania przesyłanych danych wraz z możliwością uwierzytelnienia klienta i serwera. Obie te funkcje możliwe są dzięki zastosowaniu protokołu TLS (Transport Layer Security). W tym artykule przedstawiony zostanie krok po kroku proces nawiązania szyfrowanego połączenia, który posłuży do wymiany szyfrowanych danych w HTTPS.
Począwszy od pierwszej 4-bitowej konstrukcji, rozwój mikroprocesorów przebiegał zasadniczo dwiema niezależnymi ścieżkami. Pierwsza koncentruje się wokół hardware’u i zaimplementowaniu w nim jak największej liczby funkcji. Druga zorientowana jest na software, ponieważ oprogramowanie, w odróżnieniu od sprzętu, można zaktualizować. Dlatego sprzęt powinien realizować tylko to, co musi, oraz co – ze względu na wydajność – powinien.
Firmy coraz częściej decydują się wykorzystać Pythona nawet tam, gdzie na co dzień pracuje się w innych technologiach. Ta dwuczęściowa seria artykułów powstała z myślą o menedżerach i liderach rozważających wykorzystanie Pythona. W tej części przyjrzymy się narzędziom i bibliotekom wykorzystywanym do przetwarzania danych i, szerzej, Data Science.