Dekorator to jeden se strukturalnych wzorców projektowych, dzięki któremu możemy wykorzystać kompozycję w alternatywie do dziedziczenia w celu rozszerzenia zachowania klasy. W przypadku dziedziczenia klasa rozszerzana jest w trakcie kompilacji w przeciwieństwie do dekoratorów, które rozszerzają klasy w trakcie działania programu.    Wzorzec projektowy Dekorator pozwala na dynamiczne przydzielanie danemu obiektowi nowych zachowań. Dekoratory dają elastyczność podobną do tej, jaką daje dziedziczenie, o...

TDD / Unit Testing big list of learning resources from basics to advanced topics Posted on by Michal Franc One of my fellow dev friends asked about a set of links, books, screen-casts related to TDD / Unit Testing. He wants to expand his knowledge. Instead of sending him a private message, I thought that it would be great to just create a blog post with all the resources, I used in the past to learn.Basics Presentation - Video: Unit Testing and TDD – Why You Should Care and How to Make It Happen By R...

Recently I read 3 books written by founders of Basecamp (formerly 37 Signals): David Heinemeier Hansson (creator of Ruby on Rails framework) and Jason Fried: Getting Real Rework Remote: Office not required Getting Real was written almost 10 years ago, and it talks about the same things as most recent Remote. So you can skip it. However Rework, and Remote are definitely worth to read. They present the new(?) approach for work, and productivity...

Sporo w ostatnim czasie pisałem o wzorcach projektowych. Starałem się w miarę dokładnie zgłębić ten temat i po stworzeniu kilku tekstów z tego cyklu, naszło mnie na małą refleksję - wzorce projektowe są nierozerwalnie związane z polimorfizmem. Jeśli spojrzymy na poszczególne przypadki (zwłaszcza te z grupy konstrukcyjnych wzorców projektowych), to szybko przekonamy się, że elementem spójnym jest wspólny interfejs. Pojawia się on naprawdę w wielu wzorcach.

Jakiś czas temu, pisałem o Swagger, jako sposobie na dokumentacje REST API. Dzisiaj chciałbym pokazać kolejny mechanizm na generowanie dokumentacji, tym razem napisany przez Microsoft i dostępny od razu w ASP.NET. Od kilku lat jest on już dostępny bez żadnych dodatkowych instalacji. Jeśli uruchomimy przykładową aplikację WebAPI, zobaczymy w prawym górnym rogu link do API:

Ostatnio uruchamiając synchronizację na jednym z agentów otrzymałem następujący błąd dotyczący własnego rozszerzenia: The management agent failed on run profile. The run step stopped because a required rules extension „Demo.FIM.ActiveDirectory.dll” could not be loaded. Po upewnieniu się, że wspomniana biblioteka znajduje się w katalogu Extensions zajrzałem do loga systemowego. Tam opis błędu był znacznie bardziej rozbudowany i wyglądał tak:

Największa zaleta mikro-serwisów, a mianowicie pojedyncza odpowiedzialność, często bywa również problemem, a raczej wyzwaniem. Załóżmy, że nasz system ma następujący mikro-usługi:CustomerService – podstawowe informacje o klientach AddressService – wyszukiwarka adresów CreditCardDetails – dane o kartach Nie chce wymieniać tutaj długiej listy, ale wyobraźmy sobie...

Ale o czym dzisiaj, dzisiaj o obcisłości po angielsku w programowaniu. Słowo tight będzie jednym z bohaterów wpisu. A nawet tight coupling, czyli coś mocno wiążącego. Co tak mocno wiąże w programowaniu? Moim zdanie new jest temu winny. Wiąże bowiem ono ze sobą klienta, klasę którą korzysta z new aby zaspokoić swoje potrzeby, oraz dostarczyciela usługi, czyli klasę, która jest w stanie zaspokoić tę (tą) potrzebę.

W niniejszym artykule przyjrzymy się w jaki sposób możemy przetestować klasy generyczne za pomocą funkcjonalności NUnita pod nazwą Generic Test Fixture. Dla przykładu, weźmy sobie metodę dodawania w generycznej klasie kalkulatora: public class GenericCalculator

W .net ASP.MVC są różne mechanizmy. Są też takie, które umożliwiają zbadanie argumentów przesłanych do akcji, jak i argumentów oczekiwanych w akcji. I właśnie o nich dzisiaj. Można je wykorzystywać na dobry i zły sposób, jak każde narzędzie. Najpierw mały pokaz a potem filozofowanie...