Co to jest?!?!?!

Home

Co to jest?!?!?!. Kiedyś otrzymałem mail o takim właśnie tytule, a zawierający fragment mojego kodu. Kod ten, przyznam szczerze, zbyt elegancki nie był, ale napisałem go w sytuacji rodzaju "Masz to napisać na wczoraj". Ważne, że działał i robił to co miał robić. Nie jestem człowiekiem, który uważa swój kod za święty i sądzę, że umiem przyjąć krytykę, ale ten mail nie spodobał mi się z kilku powodów.

Po pierwsze oprócz mnie został wysłany do dwóch innych osób. Po drugie w kodzie zamieściłem komentarz wyjaśniający co ten krótki fragment kodu robi. Po trzecie treść wiadomości nie zawierała żadnych wyjaśnień jak to zrobić lepiej. Innymi słowy celem tego maila było nie tyle zwrócenie mi uwagi, że coś zrobiłem nie tak, ale bardziej pokazanie innym, że coś robię nie tak.

Całą sytuację nie przejąłem no bo i po co. Na "zaczepki" tego rodzaju mam w zwyczaju nie odpowiadać chyba, że się powtarzają. Kilka godzin później otrzymałem jednak wiadomość od jednej z dwóch osób, do której skierowany był mail Co to jest?!?!?!. Wiadomość ta była skierowana bezpośrednio do autora wiadomości Co to jest?!?!?! i wyglądała mniej więcej tak:

A to CO TO JEST?!?!?!:

1. Opis błędu numer 1.
2. Opis błędu numer 2.
3. ....

Opis błędów wskazywał, że autor kodu poprzestał tylko na jego skompilowaniu i nawet jeden raz go nie uruchomił. Jak mówi stare przysłowie kto mieczem wojuje ten od miecza ginie. Krytyka jest potrzebna i często wskazana, ale krytykować trzeba umieć. Ja kiedy napotkam jakiś błąd w cudzym kodzie to trzymam się kilku zasad:

1. Nie krytykuję publicznie czyli wysyłam mail tylko do jednej osoby. Jeśli rozmawiam z osobą, w której kodzie znalazłem błąd to mówię jej o tym w dyskretny sposób.
2. Jeśli widzę, że błąd jest powszechnie popełniany to wysyłam maila to potencjalnie zainteresowanych osób i pokazuję przykład błędnego kodu ale nie wskazuję kto go napisał.
3. Krytykując staram się zawsze wyjaśnić czemu uważam, że coś jest zrobione źle i jak to zrobić lepiej.
4. Staram się aby moja wiadomość/wypowiedź nie była odebrana jako atak. Na przykład zamiast sformułowania Co to jest?!?!?! mail zatytułowałbym Błąd w metodzie SomeMethod. Taki tytuł wiadomość niesie z sobą jakąś informację i sądzę, że jest neutralny w odbiorze.
5. Zanim wyślę maila lub pójdę porozmawiać upewniam się jeszcze raz, że błąd to rzeczywiście błąd.

Publiczna krytyka niestety jest czasem potrzebna, ale tylko w "beznadziejnych" przypadkach czyli wtedy kiedy ktoś zupełnie ignoruje nasze uwagi.

Życzenia świąteczne

Home

Z okazji Świąt Bożego Narodzenia składam czytelnikom i czytelniczkom bloga serdeczne życzenia wszystkiego najlepszego oraz wybiegając trochę w przyszłość życzę dużo szczęścia i pomyślności w nadchodzącym nowym roku.

Pozdrawiam
Michał Komorowski

Dlaczego należy być upierdliwym...

Home

... kiedy dostaje się jakieś zadanie do wykonania. Albo wręcz bardzo upierdliwym i dopytywać się o wszystkie szczegóły, a przede wszystkim o te, które wydają się nam oczywiste. Odpowiedź brzmi, aby nie tracić czasu. Zasada jest prosta ale pomimo to ciągle o niej zapominam kiedy sądzę, że już wszystko rozumiem i zadanie nie jest skomplikowane. Przykład z życia.

Otrzymałem do wykonania łatwe zadanie, które upraszczając polegało na tym aby, użytkownicy domenowi nie musieli logować się ponownie do aplikacji WWW używanej wewnątrz sieci klienta. Zdecydowałem, że zastosuję Windows Authentication. Testy w środowisku lokalnym przebiegły gładko, a więc pozostało zainstalowanie aplikacji na serwerze testowym. Myślałem, że to już koniec roboty podczas gdy w rzeczywistości zajęło mi to jeszcze dużo, dużo czasu. Z jakichś powodów automatyczne logowanie nie chciało działać na docelowej maszynie. Czemu? Bo nie byłem upierdliwy i nie zadałem jednego pytania:

Czy serwer testowy został dodany do domeny?

Niestety ale przyjąłem, że znajduje się w domenie, do której należą użytkownicy (warunek konieczny automatycznego logowania) i przyczyny kłopotów szukałem wszędzie tylko nie tam gdzie potrzeba. Bądźmy, więc upierdliwi i kiedy dostajemy zadanie pytajmy, pytajmy i jeszcze raz pytajmy.

Reporting Services i schowane etykiety

Home

Poniższy rysunek zawiera fragment wykresu wygenerowanego przez SQL Server Reporting Services. Wykres ten przedstawia wartość pewnej miary (oś OY) dla różnych kategorii (oś OX). Mniejsza o jaką miarę i kategorię chodzi. Problem polega na tym, że etykiety posiadają tylko niektóre słupki, a nie wszystkie co czyni wykres bezużytecznym. Nie sposób bowiem wydedukować jakie kategorie zostały pokazane np.: pomiędzy JNZ i OR.



Nie zastanawiając się długo postanowiłem, więc dodać etykiety dla wszystkich słupków. Wbrew pozorom znalezienie rozwiązania zajęło mi trochę czasu, a rozwiązanie okazało się mało intuicyjne. Zacząłem od przejrzeniu wszystkich okienek kreatora wykresu i wypróbowaniu różnych przełączników. Niestety bez sukcesu. Następnie zauważyłem, że okno Properties dla osi OX zawiera dużo, dużo więcej właściwości niż jest udostępnione w kreatorze, żeby nie skłamać dobre kilkadziesiąt. Trochę już zniechęcony postanowiłem je przejrzeć i po chwili znalazłem grupę właściwości o nazwach zaczynających się od Label, a wśród nich właściwość LabelInterval ustawioną na wartość Auto.



Zgodnie z nazwą właściwość ta powinna określać krok co jaki będą wyświetlane etykiety. Opis właściwości (Labels interval size) to masło maślane ale co szkodzi sprawdzić. Zamiast Auto wpisałem więc 1. Okazało się to strzałem w dziesiątkę. Po tej niewielkiej zmianie wykres prezentuje się jak poniżej:

Czemu VB.NET jest be?

Home

Z językiem VB.NET da się pracować, co z powodzeniem czynię od blisko roku, ale niektóre rzeczy doprowadzają mnie do szału. Aby wyjaśnic o co chodzi posłużę się bardzo, bardzo prostym interfejsem pokazanym poniżej:

Public Interface IFun
  Function Fun() As Integer
  Function SuperFun() As Integer
End Interface

Implementacja funkcji Fun oraz SuperFun jest trywialna i wyglądają jak poniżej:

Public Function Fun() As Integer
  Return 0
End Function

Public Function SuperFun() As Integer
  Return 1
End Function

Jeszcze kod, który korzysta z tej implementacji:

Sub Main()
  Dim fun As Fun = New Fun()
  Dim ifun As IFun = fun

  Console.WriteLine(fun.Fun() = ifun.Fun())
  Console.WriteLine(fun.SuperFun() = ifun.SuperFun())
  Console.WriteLine(fun.Fun() = ifun.SuperFun())
  Console.WriteLine(fun.SuperFun() = ifun.Fun())
End Sub

A na koniec pytanie, jaki wynik zostanie wypisany na ekan? Założę się, że nikt się nie zawacha i odpowie:

True
True
False
False

Taki wynik jest oczywiście logiczny i prawidłowy ale nie zawsze, w przypadku VB.NET można uzyskać również taki wynik:

False
False
True
True

Nie trzeba do tego stosować żadnych sztuczek, wystarczy zwykła pomyłka. Pokazując implementację metod Fun oraz SuperFun celowo pominąłem słowo kluczowe Implements, które określa jaki element intefejsu implementuje dana metoda. Kod klasy powinien wyglądać tak:

Public Class Fun
  Implements IFun

  Public Function Fun() As Integer Implements IFun.Fun
    Return 0
  End Function

  Public Function SuperFun() As Integer Implements IFun.SuperFun
    Return 1
  End Function
End Class

Niestety ponieważ metody Fun oraz SuperFun mają takie same sygnatury to nic nie stoi na przeszkodzie aby zamienić miejscami Implements IFun.Fun z Implements IFun.SuperFun i otrzymać coś takiego:

Public Class Fun
  Implements IFun

  Public Function Fun() As Integer Implements IFun.SuperFun
    Return 0
  End Function

  Public Function SuperFun() As Integer Implements IFun.Fun
    Return 1
  End Function
End Class

Mały, wkurzajacy i bardzo trudny do wykrycia błąd wynikający z cech języka VB.NET.