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.

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:

Już od jakiegoś czasu dość aktywnie (choć z przerwami) udzielam się na StackOverflow wokół tagów .NET/C#. Pomyślałem, że przekroczenie okrągłych 10k punktów jest dobrą okazją do spisania swoich różnorakich przemyśleń na temat tego serwisu.

Czasami zachodzi potrzeba ponownego wykonania jakiegoś kodu, w przypadku np. wyrzucenia błędu. Można samemu zaimplementować to za pomocą np. pętli, kontynuować daną operację w kolejnych iteracjach. Problem w tym, że taki mechanizm można dość znacząco rozbudowywać. Zwykle, chcemy poczekać przed następną iteracją ponieważ szanse, że ponowna próba, natychmiast po pierwszej próbie zakończy się sukcesem jest niska. Ponadto, zdefiniowanie “niepowodzenia” też jest dość skomplikowane. Polly to mała, ale dość ...

Z życia wzięta historia .NETowca, który po przeprowadzce zaczął nowe życie z MSSQL. Ku pokrzepieniu serc, że jest jeszcze nadzieja. A SSDT może pomóc ją urzeczywistnić.

Dzisiaj chciałbym pokazać Swagger, doskonałe narzędzie służące do dokumentacji REST API. Swagger, korzysta z plików JSON, którymi można opisać nasze API. W przypadku RESTful api m.in. możemy określić:Nazwę zasobuTyp zwracanych danychOpis obiektówWersję APIZwracane kody statusu HTTPParametry (np. query lub HTTP body)HTTP verbs (PUT, GET, POST etc)

OObsługa błędów nigdy nie była łatwym zadaniem, ale w większości przypadków zawsze wiedziałem z czego mogę skorzystać. Myślałem że z ASP.NET MVC będzie podobnie, a może nawet lepiej (w końcu jest to dosyć dobrze przemyślana platforma, co wielokrotnie już podkreślałem na blogu) i po części tak jest w istocie - mamy tu wręcz nadmiar możliwości...

Dobry programista zawsze będzie się starał pisać czytelny kod. Kluczem do sukcesu jest w tym przypadku ciągła refaktoryzacja wsparta wzorcami projektowymi. Wzorce projektowe w wielu przypadkach pozwalają na zapewnienie elastycznych i skalowalnych rozwiązań, a ponadto sprzyjają w tworzeniu unikalnego kodu. Oczywiście nieodpowiednio użyte mogą również zaszkodzić - tak jak inne rzeczy w naszym codziennym życiu;-)

Jeśli ktoś spytałby mnie o element który kojarzy mi się z programowaniem niezależnie od zastosowanego języka, to odpowiedziałbym prosto - instrukcje warunkowe. Wszelkiej maści IFy i switche pojawiają się w praktycznie każdym szanującym się języku programowania i tak naprawdę trudno sobie wyobrazić jakąkolwiek sensowną aplikację, która by z nich nie korzystała. I choć w teorii dają one wiele dobrego, to w praktyce, przy nieodpowiednim użyciu, mogą w sposób znaczący obniżyć czytelność tworzonego kodu.

Ostatnio w pracy miałem do rozwikłania pewien banalny problem (przynajmniej tak mi się pierwotnie wydawało). Moim zadaniem było znalezienie programowego rozwiązania, które w sposób jednoznaczny pozwoli zidentyfikować smartfon z systemem Windows Phone. Aplikacja wykorzystywała architekturę WinRT (Universal Apps).