AuthorPatryk

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.

Recesja a Twój stołek

Ostatnio w pracy, został poruszony temat ogólnoświatowej recesji wieszczonej od jakiegoś czasu i jej wpływu na naszą, stricte IT, branżę. Sprawa zainteresowała mnie na tyle, że postanowiłem napisać coś w tym temacie.

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”...

Newsletter



Społecznościowe

Historycznie

Tagi