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”...
Praca z Gitem. Nie tylko okienka, nie tylko konsola.
Słowem wstępu Praca z Gitem. Dużo się o nim mówi, zwłaszcza w środowisku .NET, głównie ze względu na to iż Microsoft kupił Github, a także udostępnił źródła .NET Standard i .NET Core na licencji Open Source (MIT). Osobiście, ciągle się uczę Gita i przy okazji sprawdzam, testuję różne rozwiązania około-gitowe. Wtyczki, narzędzia, różnego rodzaju integracje z Gitem. To sprawia, że wiem co mogę i ile mogę. Gita świetnie się obsługuje z poziomu konsoli czy terminala i przy tym pozostanę, ale zawsze dobrze mieć coś w zanadrzu. Zamysł Ludzie są różni i różne potrzeby mają. Ha! Taki komunał na początek. Dlatego nie każdy będzie używać konsoli do pracy z Gitem. Osobiście uważam że jest to najlepsza droga ku temu, ale hej…każdy lubi „po swojemu”. Do tematu podszedłem od strony czysto użytkowej. Git jest wspaniały ale, jak ze wszystkim, nie dla każdego. Owszem, da się, ale czy to oznacza, że od razu trzeba? Dlatego filozofie nt. tego czy trzeba czy nie, zostawiam na...
