Każdy z nas jest choć trochę leniwy. Jedni troszkę mniej, inni troszkę bardziej. Ja na ten przykład czasem się rozpędzam i piszę kod, który potrzebuje. Potem o nim opowiadam, a potem ktoś pyta czemu nie skorzystałem z jakiejś tam gotowej biblioteki. Wiem, że każdy z nas należy do mensy i wie, że ten wpis nie wziął się z powietrza.

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.

Największa zaleta mikro-serwisów, a mianowicie pojedyncza odpowiedzialność, często bywa również problemem, a raczej wyzwaniem. Załóżmy, że nasz system ma następujący mikro-usługi:CustomerService – podstawowe informacje o klientach AddressService – wyszukiwarka adresów CreditCardDetails – dane o kartach Nie chce wymieniać tutaj długiej listy, ale wyobraźmy sobie...

Przemysław Walkowski Kontynuując temat bezpieczeństwa, chce zająć się tematem certyfikatów ich tworzeniem i obsługą. Omówię co to jest PKI, CA, X.509. To o czym nie wspomniałem w ostatnim poście a może przydać się w tym poście to wiedza o tym, że algorytm asymetryczny z kluczem publicznym i prywatnym ma możliwość szyfrowania danych przy pomocy klucza publicznego jak i prywatnego. Gdy zaszyfrujemy dane kluczem prywatnym, będziemy mieć możliwość...

Ale o czym dzisiaj, dzisiaj o obcisłości po angielsku w programowaniu. Słowo tight będzie jednym z bohaterów wpisu. A nawet tight coupling, czyli coś mocno wiążącego. Co tak mocno wiąże w programowaniu? Moim zdanie new jest temu winny. Wiąże bowiem ono ze sobą klienta, klasę którą korzysta z new aby zaspokoić swoje potrzeby, oraz dostarczyciela usługi, czyli klasę, która jest w stanie zaspokoić tę (tą) potrzebę.

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

W ostatnim temacie cyklu poświęconego usłudze Azure Service Bus chciałbym przedstawić bardziej rozbudowane scenariusze pracy z wiadomościami takie jak: obsługa pod-kolejek DeadLetter, opóźnione przetwarzanie, wykrywanie zdublowanych wiadomości, harmonogram dostarczania wiadomości, transakcje przy wysyłaniu i odbieraniu wielu wiadomości, sesje oraz praca w modelu request-response.

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.