Szukasz jakiegoś taniego albo darmowego rozwiązania, aby hostować swoją aplikację napisaną w .NET Core? Otóż pomocą przychodzi Heroku!
Stryker Mutator i Testy Mutacyjne w .NET. Szybki start.
Testy mutacyjne. Szybki start i biblioteka Stryker w .NET i dotnetcore. Pierwsze uruchomienie, szybkie spojrzenie na rezultaty testów.
.NET i Code Coverage w VS Code – Tutorial
Code coverage? Podoba mi się idea pokazywania które fragmenty kodu testami są pokryte, a które nie. Jak tego dokonać w środowisku VS Code? Sprawdź.
Dapper – Czy mniej znaczy więcej?
W tym wpisie chciałbym poruszyć temat biblioteki Dapper. Będzie to krótka zajawka pokazująca sposób użycia i to, jak niskim nakładem pracy można zacząć używać Dapper'a. Sami oceńcie.
Nuget serwer mnie nie lubi
Dzisiaj temat podyktowany moim lekkim wk^@wem. Mianowicie zdenerwowałem się na serwer Nuget.
Nie SOLID-nie #05: Dependency Inversion Principle
Robert C. Martin (Uncle Bob) w swoim artykule nt. Dependency Inversion Principle, skondensowanej wersji rozdziału "DIP: The Dependency-Inversion Principle" ze swojej książki pt. Agile Software Development, Principles, Patterns and Practices, opisuje "zły" design aplikacji i wprowadza pojęcie "kruchości" aplikacji.
Nie SOLID-nie #04: Interface Segregation Principle
Zasadniczo ISP mówi o "rozczłonkowaniu" dużych, wielozadaniowych kontraktów i interfejsów na mniejsze, posiadające jedną konkretną odpowiedzialność. Dzięki czemu, każdy element który konsumuje taki interfejs, ma dostęp tylko do określonej funkcjonalnośći.
Nie SOLID-nie #03: Liskov Substitution Principle
Jak podaje Wikipedia, zasada ta została sformułowana po raz pierwszy przez Barbarę Liskov i Jannette Wing we wspólnej pracy pt. "A Behavioral Notion of Subtyping", zaprezentowana przez Panią Liskov w przemówieniu pt. "Data Abstraction and Hierarchy", a spopularyzowana i podana w obecnym brzmieniu przez Roberta C. Martina w artykule "Principles of Object Oriented Design" oraz książce "Agile Software Development: Principles, Patterns, and Practices"
Nie SOLID-nie #02: Open Close Principle
Reguła Open Close Principle mówi o tym, że klasa powinna być otwarta na rozszerzenia i jednocześnie zamknięta na modyfikacje. Zgodnie z zasadą tego cyklu - "Nie SOLID-nie", przedstawiam jak może wyglądać klasa napisana wbrew tej regule.
Nie SOLID-nie #01: Single Responsibility Principle
Wikipedia podaje, że SOLID to ukuty przez Roberta C. Martina mnemonik. Wystarczy jednak zapamiętać, że jest to zbiór zasad jakimi powinien się kierować programista, podczas pisania kodu. Zwłaszcza w paradygmacie programowania obiektowego.