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.
Continuous integration#03: Docker. Containers. Swarm.
Trzeci post nt. Continuous Integration. Omówienie i krótki wstęp do inicjalizacji docker swarm, w celu utworzenia środowiska dla testów build serwerów. „Warsztat smokogromcy” „Atrybuty smoczego pogromcy” „Docker. Containers. Swarm.” Podejście kolejne Od czasu ostatniego wpisu dotyczącego Continous Integration, Continous Delivery, Continous Deployment, w kontekście testu build serwerów, minęło kilka miesięcy. W tym czasie popełniłem kilka mniej wymagających (ale nie mniej znaczących!) postów. Nabrałem trochę wprawy w blogowaniu i w wyrażaniu własnych myśli, a także nauczyłem się sporo w dziedzinie samej „developerki”. Uznałem, że czas powrócić do tematu automatyzacji, pobawić się trochę DevOpsowymi zabawkami. Na dobrej zabawie, czas szybko płynie. W tym wpisie wyjaśniam, jak widzę dalszą pracę z przygotowaniem środowiska i jak widzę kolejne kroki. Zastrzegam również, że jestem przygotowany na „bunt maszyn”...