Aplikacje powinny uwzględniać udogodnienia dostarczane przez sprzęt komputerowy i system operacyjny. Dotyczy to przede wszystkim programów, które mają wydajnie obsługiwać wielu niezależnych klientów lub wiele urządzeń. Biblioteka Boost.Asio pozwala tworzyć w języku C++ przenośne moduły służące do komunikacji.

Profesjonalne tworzenie aplikacji w językach natywnych wiąże się z niemałą odpowiedzialnością - oprócz prawidłowej implementacji logiki aplikacji, developer jest zmuszony bezwzględnie przestrzegać reguł poprawnego operowania na pamięci. Potencjalne błędy drugiej grupy są - a raczej były - niesłychanie trudne w debugowaniu. Na ratunek przychodzi nam młody projekt o nazwie AddressSanitizer, który szybko i precyzyjnie wskazuje moment i kontekst wystąpienia błędnego odwołania do pamięci.

W szóstej części kursu „Wprowadzenie do języka C# i platformy .NET” bliżej przyjrzymy się delegatom, zdarzeniom i strumieniom – niezwykle istotnym elementom podczas korzystania z platformy .NET.

Jedną z ważnych zalet platformy .NET jest wielojęzyczność, objawiająca się m.in. możliwością współpracy z obiektami i klasami utworzonymi w różnych językach programowania. Pakiet Cudafy.NET to rozwiązanie wykorzystujące w pełni tę własność .NETu, gdyż pozwala na tworzenie aplikacji wykorzystujących technologię CUDA przy zastosowaniu języka C#, bez konieczności bezpośredniego kodowania procedur obliczeniowych w CUDA C/C++.

Programowanie aplikacji wizualnych stało się obecnie bardzo proste za przyczyną dużej liczby publicznie dostępnych (i często darmowych) frameworków i bibliotek uruchomieniowych. VCL, LCL, MFC, Windows Forms, wxWidgets, Qt, FireMonkey – żeby wymienić kilka najbardziej popularnych. Korzystanie z nich pozwala na ograniczenie czasu potrzebnego na napisanie programu, bo zamiast mozolnie implementować interface, programista może skupić się na faktycznym problemie do rozwiązania. Zdarzają się jednak sytuacje, gdy wiedza na temat niskopoziomowej obsługi okien i kontrolek okazuje się być bardzo przydatna – i to właśnie o niej chciałbym opowiedzieć w niniejszym artykule.

Jak wykorzystać Dependency Injection w swoich aplikacjach? Dlaczego nie każde użycie kontenera DI jest zastosowaniem wzorca DI? Kiedy rejestrować komponent w kodzie, a kiedy w zewnętrznym pliku? Jak testować kod przygotowany do wstrzykiwania? Jak wzorzec fabryki wpasowuje się w koncepcję DI?

Passbook jest aplikacją przeznaczoną do obsługi ważnych kart zawierających kody kreskowe. Dzięki niej można nie tylko wyświetlać nowe karty, ale również zapisywać je w książce i nimi zarządzać. Na kartach wyświetlane są istotne informacje zawarte w kodzie, potrzebne do wymaganej weryfikacji. Dzięki danym z GPS system może informować o tym, że użytkownik znajduje się blisko miejsca, z którego karta została wydana.

Celem tego artykułu jest dokładniejsze przedstawienie działania modeli. Dowiemy się, czym charakteryzują się klasy modeli, jaką rolę spełniają oraz jak od strony programistycznej wygląda praca z nimi.

Popularne wśród programistów powiedzenie głosi, że aby zrozumieć rekurencję, należy najpierw zrozumieć rekurencję. Nawet wyszukiwarka Google po wpisaniu słowa „rekurencja” wyświetla podpowiedź: „Czy chodziło Ci o rekurencja”. Rekurencja stanowi podstawę wielu algorytmów, ale jej wykorzystanie uważa się czasem za nieefektywne i dość ryzykowne. Tymczasem wcale nie taki diabeł straszny jak go malują i przy znajomości kilku trików można się z rekurencją wręcz zaprzyjaźnić.

Stare powiedzenie, które często przewija się przy okazji kontroli projektów, to „Śmieci na wejściu, śmieci na wyjściu.” Każda metoda i proces są skazane na porażkę, jeżeli będziemy pracować z błędnymi danymi wejściowymi. W Agile pomiar postępu prac, rozmiaru Backloga i określenie harmonogramu projektu ściśle polegają na umiejętności szacowania przez członków zespołu. Szacunek User Story to dane wejściowe do planowania. Jeśli zespół będzie przypisywał złe wartości, to nikt nie będzie mógł dobrze przewidzieć postępu prac i jakikolwiek plan będzie nadawał się tylko do wyrzucenia do kosza, obojętnie czy stosujemy metody Fixed Scope, czy Fixed Date, o których pisałem wcześniej. Również codzienny postęp prac jest oparty na bieżącej estymacji zadań. Więc trzeba robić to jak najlepiej.

Testując jednostkowo sieć powiązanych obiektów, dążymy do ich testowania w separacji. Separację osiągamy dzięki stosowaniu różnego rodzaju „dublerów”. Często bez zastanowienia stosujemy dublery typu Mock. Mocki są relatywnie pracochłonną techniką, która nie zawsze jest uzasadniona. W niniejszym artykule zostanie przedstawiona pragmatyczna „reguła kciuka” oparta o paradygmat Command-query Separation, która daje prostą odpowiedź co do typu dublera, jakiego potrzebujemy w teście jednostkowym.

Sformułowanie „projektowanie systemów informatycznych“, jako powszechne w użyciu, nabrało wielu znaczeń. W różnych środowiskach spotyka się różne jego definicje. Czasami nawiązuje bezpośrednio do zagadnień programowania, gdzie mowa wprost o wyższej jakości kodu. Innym znów razem, wypowiadane przez chociażby menadżerów przedsięwzięć IT, nawiązuje do takiej pracy, która scala większe/często kompletne rozwiązania IT. Co również przekłada się na wyższą jakość kodu, ale i przede wszystkim – zapewnia świadomość panowania nad realizacją projektu.

Popularną metodą pracy, szczególnie w młodych startupach, jest rezygnacja z jakichkolwiek ram, reguł, praktyk czy zasad. Choć brzmi to niedorzecznie, pewnie każdy z nas zna firmę, która rozpoczynając działalność, funkcjonowała w podobnym, niepoukładanym środowisku. Brak efektywnego procesu wytwarzania oprogramowania sprawia, że firmy – pomimo posiadania ciekawych pomysłów na biznes – bezrefleksyjnie dryfują na spotkanie z górą lodową.

Jednym z wyzwań, przed jakim stajesz, zostając liderem zespołu lub kierownikiem działu IT, jest zbudowanie autorytetu wśród osób, którymi będziesz zarządzać. Zaczynasz wtedy zadawać sobie pytanie, jak to zrobić? Znalezienie odpowiedzi na to pytanie może wydawać Ci się trudne. Jednak wszystko zależy od tego, gdzie ich szukasz. A najlepsze odpowiedzi są często bliżej, niż myślisz. Trzeba zadać tylko odpowiednie pytania.