Dzielenie z resztą bez rzutowania na float

Aby dzielenie odbyło się z resztą operacja musi się odbyć na typach double a nie na int, czyli żeby wynik nie był zaokrąglony do inta. W praktyce dzielenie na intach:

int result = 4/3; // result == 1
Kiedyś rzutowałem w ten sposób:
int rowsNeeded = (int)Math.Ceiling((double)Sources.Count / 2);
A od dziś dzięki Grzesiowi będę zmieniał drugą liczbę na explicit double (2D):
int rowsNeeded = (int)Math.Ceiling(Sources.Count / 2D);

Analogicznie dla decimal (literka M)

decimal amount = 4M;

[StyleCop] Jakie severity (Warning czy Error) dla problemów zgłaszanych przez StyleCop?

Opiszę pomysł, który zobaczyłem w projekcie i bardzo mi się spodobał. Nie będę opisywał możliwych modyfikacji, które sobie wyobrażam. Rozumiem też, że będąc w innym projekcie (Context is King!) musiałbym go dostosować.

Errory tylko w Release

Gdy piszemy kod to zazwyczaj jesteśmy w „Debug”, i w takim trybie nie chcemy dostawać Errorów do StyleCopa. Powodów może być wiele: kod experymentalny, kod przeklejony z internetu, z poprzedniego projektu, itp. Albo po prostu każdy ma inną wrażliwość na to jak formatować kod. I lokalnie niech się każdemu kompiluje i pokazuje Warningi, ale niech się odpala.

Jednak w kodzie produkcyjnym, którym dzielimy się z wszystkimi, gdzie przechodzi Build Script na serwerze Continuous Integration – chcemy mieć czysto. Dlatego mamy drugi ruleset dla trybu „Release”, w tym drugim wszystkie reguły traktowane są jako Errory. W skrypcie jest więc osobny krok, który odpowiada za zbudowanie solucji w trybie „Release”.

Przykład ze skryptu PowerShellowego (używającego Psake):

Przykładowe rulesety (wycinki)

Debug:

<Rule Id="SA1405" Action="Warning" />
<Rule Id="SA1406" Action="Warning" />
<Rule Id="SA1407" Action="None" />

Release:

<Rule Id="SA1405" Action="Error" />
<Rule Id="SA1406" Action="Error" />
<Rule Id="SA1407" Action="None" />

Domyślnie wszystko jest Warningiem

Dzięki temu plik z regułami jest krótszy. Odstępstwo od reguły będzie Warningiem. W pliku *Debug.ruleset to co chcemy ignorować dodajemy jako:

<Rule Id="SA1407" Action="None" />

Jednak w pliku *Release.ruleset musimy severity tych wszystkich domyślnych reguł potraktować jako „error”.

Co za tym idzie najlepiej w obydwu plikach mieć explicite wszystkie reguły. Wtedy ręcznie w obydwu naraz zmieniamy gdy chcemy zmienić podejście do którejś reguły.

Konflikty korzystania z Configuration

Minusem jest to, że Configuration (Debug/Release) nie jest do takich zastosowań. Może być też używana przez inne narzędzia. Obecnie w projekcie gryzie się to z BenchmarkDotNet. Jest on odpalany tylko w trybie „Release” i wtedy StyleCop musi być na czysto. Więc nachodzą na siebie, ale da się z tym żyć, nie jest problematyczne.

Zalogowanie ustawień podczas startu applikacji

Zawsze przychodzi ten moment gdy trzeba rozwiązać buga na produkcji i jedyne co mamy to logi aplikacji. Okazuje się oczywiście, że nie ma wszystkich informacji w tych logach. Nie ma nawet całkiem podstawowych informacji.

Gdy nic nie widzisz

Spotkałem się z sytuacją gdzie był robiony request do serwisu, ale nie wiadomo było do którego dokładnie (brak urla w logach). Innym razem pliki były gdzieś przekopiowywane, ale nie było wiadomo gdzie. Dlaczego doszukanie się tych informacji jest takie trudne (choć nie powinno)?

search for bug in code

Przykładowo aplikacja wchodzi w skład większych bytów, jest uruchamiana prze inne aplikacje itd. Zdarza się, że w takich systemach nieporządek jest czymś powszechnym. Cykl releasowania jest skomplikowany na tyle, że nie możemy dorzucić kilku logów w problematycznych miejscach i wypuścić update’u.

Zaloguje wszystko raz, a dobrze

Moja propozycja, zrób jeden obiekt Settings, który zbiera wszystkie ustawienia, początkowe. Bardzo możliwe, że taki obiekt już jest (Od Krzyśka Seroki: W przypadku ASP.NET Core mamy IConfiguration). Podczas startu aplikacji trzeba te wszystkie ustawienia zebrać (z linii komend, z pliku/ów konfiguracyjnych, z bazy, wygenerowane ścieżki np. na podstawie UserName). To podejście jest dobre samo w sobie bo robimy to raz a serwis, który je udostępnia jest zarejestrowany w kontenerze Dependency Injection jako singleton.

Jeśli takiego obiektu nie mamy to możemy go stworzyć nawet dynamicznie. Możemy nazywać explicite pole lub pozostawić domyślne nazwy:

Następnie serializujemy ten obiekt do JSONa i zapisujemy w logu. Pełny przykładowy kod:

JSON po serializacji:

Bezpieczeństwo!

Trzeba jeszcze pamiętać o ukryciu ewentualnych haseł. Najprościej zrobić to nullując odpowiednie pola. Wiem, wiem, wiem, przyjdzie Junior, zapomni i hasła wyciekną… Przecież dzielicie się wiedzą w projekcie i macie Code Review, co nie?

Testivus – kompletne starożytne nauki na temat testowania

Moje motto na temat Unit Testów i wielu innych rzeczy:

Less Unit Testing Dogma
More Unit Testing Karma

Nie ma co pisać wstępów, trzeba przeczytać krótkiego i zwięzłego PDFa The Way of Testivus

Good advice on developer and unit testing, packaged
as twelve cryptic bits of ancient Eastern wisdom.

Testivus Unit Testing

Mnie to olśniło, rzadko zdarza się dorwać coś, co jest tak fajnie przygotowane i aż się prosi o wydrukowanie.

Podzieliłem się moim odkryciem tak, że wydrukowałem w kolorze (dzięki Sylwia Lasek 🙂 ), zbindowałem i rozdałem osobom zainteresowanym tematem aby je zainspirować.

Trafiłem na Testivusa szukająć przykładów dlaczego pułap Code Coverage nie powinien być żadnym celem. Na SO znalazłem wytłumaczenie What is a reasonable code coverage % for unit tests (and why)?

Static – dobry, zły i brzydki

Prywatne pola static – są bardzo NIE OK.
Metody static – są OK.

I o ile jest generalnie zgoda, że nie powinno się używać static w polach to chciałem pokazać, że metody będące statyczne są dobre. Czy powinny być statyczne to zależy od kontekstu. Ja stosuję to tak, że kiedy mogę to staram się przekazać argumenty i uczynić metodę statyczną. Przykłady takich metod z mojego kodu:

Przypadki, gdy zdarzają się publiczne właściwości:

  • ServiceLocator – generalnie antypattern, ale czasem inaczej się nie da i gdy wiem co robię to pozwalam sobie na to.
  • Puste obiekty, gdy sa immutable i mogą być reużywane, przykład EventArgs:
  • … (można dodać w komentarzach)

Przypadki, gdy można uniknąć statycznych publicznych właściwości:

  • Singleton => można rejestrować jako „AsSingleton” w kontenerze IoC.
  • Jest klasa (serwis), która ma stan, i takich instancji jest wiele w aplikacji. Dodatkowo potrzebuję dostęp do jakiejś statycznej kolekcji. Najprościej jest utworzyć jedno pole static, którego będą reużywać wszystkie instancje. Nie robiłbym tak. Lepiej jest tą część, która wydaje się być statyczna wydzielić do innego bytu i przekazać jako zależność, a w kontenerze zarejestrować jako AsSingleton (punkt wyżej).

Przyspieszone słuchanie podcastów i konferencji

play youtube faster

Czy oglądając video z konferencji nie nudzicie się czasem? Może za wolno? Zdecydowanie tak. Kiedykolwiek to pokazuję to każdy się zgadza, że można przyspieszyć.

Np. w youtube w prawym dolnym rogu klikamy Settings->Speed i dostaniemy wybór jak po prawej.

W Windows Media Player klikamy PPM->Enhancements->”Play speed settings”:

play windows media player faster

Oraz mój ulubiony (na androidzie), czyli prosty Music Speed Changer (to był jedyny który ściągnąłem, chętnie posłucham gdy są lepsze):

Android Music Speed Changer

Zyski

Ja oszczędzam w ten sposób bardzo dużo czasu. Gdy chodzi o podcasty to słucham na ok 140%. Gdy czasem ktoś mówi zbyt szybko to zmniejszam do 130%. W ten bardzo prosty sposób w 30 minut wchłaniam wiedzę z 40 minut.

Dobra muza do kodowania

Wiadomo jest to bardzo subiektywne. Wracam jednak często po podobne bity, więc tak bardziej dla siebie wrzuciłem wreszcie na bloga.

Niech się stanie FLOW

i kolejne części „Concentration \ Programming Music”

Pomodoro

Polecam równocześnie technikę pomodoro i ustawianie czasu na 25minut pracy, 5minut przerwy. Mój programik to http://e.ggtimer.com/pomodoro