27 lipca 2011

Programista i jego Troubleshooting Toolkit (Część II) - .NET

Rozwiązywanie problemów na platformie .NET


W kolejnym poście skupię się na temacie rozwiązywania problemów na platformie .NET z którymi borykają się programiści. Jest to zagadnienie bliskie memu sercu, ponieważ jako etatowy "detektyw .NET" wielokrotnie byłem zmuszony do korzystania z większości z tych narzędzi, szczególnie gdy zawiodło mnie bezmyślne wyszukanie w Google.

22 lipca 2011

Nie ignoruj bluescreen'a

Analiza crush dump'a - podstway


Niedawno obejrzałem dosyć stary już webcast Windows Hang and Crash Dump Analysis, w którym Mark Russinovich (człowiek od Sysinternals Suite) udowodnił mi, że nie trzeba być geniuszem, żeby wykonać analizę crush dump'a (bluescreen przeważnie produkuje memory dumpa). Czytelników spragnionych szczegółów i dokładniejszych wyjaśnień odsyłam do obejrzenia w całości tego ciekawego webcast'u.

Bluescreen - zdarzy się, ale kto by się przejmował


Na szczęście na codzień w pracy nie muszę zajmować się środowiskiem serwerowym, zatem większość bluescreen'ów otrzymałem na moich stacjach roboczych (w pracy, w domu). Czasami efektem bluescreen'u może być niespodziewany restart. Niestety nigdy nie wpadłem na pomysł, żeby przeprowadzić bardziej wnikliwą analizę tego zjawiska. Podczas crash'u memory dump najpierw zapisywany jest do page file'a, a później generowany jest memory dump (mini-dumpy są zawsze generowany z datą w nazwie pliku, u mnie  lądują w folderze C:\Windows\Minidump\ ). W Windows 7 Microsoft zostawił tylko możliwość generowania zrzutów Kernel-memory lub Small memory dump, w sumie zrzut 8GB pamięci na dysk trochę by musiał trwać i wymagałby dodatkowego miejsca na dysku. (Aby dostać się do ustawień rodzaju zrzutu pamięci wybierz prawym Computer później Properties -> Advanced System settings -> Zakładka Advanced ->Wybierz dla Startup and Recovery przycisk Settings. ).



20 lipca 2011

Programista i jego Troubleshooting Toolkit (Część I) - Przeglądanie logów

Programista i rozwiązywanie problemów

Postanowiłem opublikować kilka postów o narzędziach, które mogą pomóc programistom w rozwiązywaniu problemów z oprogramowaniem na platformie Windows. Nie zawsze możemy debuggować kod źródłowy oprogramowania z którym przyszło name pracować. Często jesteśmy użytkownikiem produktu od zewnętrznego producenta (np. Microsoft) i nie możemy zmusić danego programu, komponentu do działania.

Poszukiwany, poszukiwana


W poniższym poście przedstawiam narzędzia z których korzystam na codzień gdy muszę przeanalizować logi (np. w formie pliku tesktowego). Podejrzewam, że nawet najszczęśliwszy programista musi czasami przejrzeć logi w poszukiwaniu błędów, wskazówek, wyjątków itd. Opracowałem listę narzędzi, które mogą być pomocne przy przeglądaniu różnego rodzaju logów na platformie Windows.


Tail for Win32

Tail for Win32 jest sympatycznym programem do śledzenia "ogonka" logu. Jest on bardzo przydatny w sytuacji gdy monitorujemy zmiany na bieżąco i nie chcemy w nieskończoność przeładowywać danego pliku w edytorze tekstu. Program umożliwia też definiowanie i kolorowanie słów kluczowych (np. service i stopped na załączonym obrazku poniżej).





Opcja którą najbardziej cenię:
Możliwość obserwacji kilku plików w tym samym momencie (nawet na różnych serwerach). 

13 lipca 2011

NDoc3 - Jak wygenerować dokumentację w 5 minut?

Mam 5 minut na wygenerowanie dokumentacji


Tworzenie dokumentacji kodu źródłowego (np. publicznych typów, metod API) jest czasochłonne i "nudne". Aczkolwiek wyniki tej pracy mogą być bardzo przydatne dla programistów używających dane oprogramowanie. Ponieważ, wielu programistów lubi korzystać z dokumentacji API w formacie CHM postanowiłem dodać taki artefakt do mojego projektu Weather.com C# .NET client.  Chciałem poświęcić tej czynności minimalną ilość czasu, zacząłem więc od popularnego Sandcastle. Niestety po 20 minutach i próbach instalacji, konfiguracji, zrozumienia koncepcji poddałem się. Nie oznacza to, że Sandcastle nie jest dobrym produktem, ale moim głównym kryterium było wygenerowanie CHM'a w 5 minut.

Aby wygenerować jakąkolwiek dokumentację CHM należy zainstalować HTML Help Workshop and Documentation.  

NDoc3 na ratunek

Następnym programem który uruchomiłem był NDoc3, reaktywacja kiedyś popularnego NDoc'a. Zostałem bardzo miło zaskoczony, gdyż po 5 minutach miałem wygenerowanego CHM'a dla mojej biblioteki, który wyglądał następująco.



12 lipca 2011

XSLT, XslCompiledTransform i modularność w transformacjach

Wysoka temperatura, XSL i modularność


W ramach implementacji wersji 1.0 Weather.com C# .NET client postanowiłem dodać przykładową transformację XML'a zwracanego przez usługę Weather.com. Jako, że użycie arkusza XSL wydawało mi się najprostsze, przygotowałem prostą transofrmację. Usługa zwraca dane o aktualnym stanie pogody, ale jest też możliwe pobranie prognozy pogody na najbliższe dni. Oba wyniki zwracane przez usługę Weather.com w formacie XML mają podobną strukturę. Jako, że używam XSLT od "wielkiego dzwonu", wychodzi średnio raz na rok, to musiałem poszperać, czy istnieje możliwość pisania "modułów" które mogą być współdzielone pomiędzy arkuszami XSL.

<xsl:include />


Okazuje się, że XSL posiada dyrektywę <xsl:include /> która umożliwia importowanie zewnętrznych arkuszów. W każdym z dwóch formatów XMLa z aktualnymi warunkami pogodowymi i prognozą pogody, powielały się pewne elementy. Szczególnie istotne były jednostki temperatury, ciśnienia etc,  które były później wykorzystywane do formatowania wyników. Załużmy, że dysponujemy poniższych plikiem XML, który chcemy przekształcić w dokument HTML.

Sample.xml file

<?xml version="1.0" encoding="UTF-8"?>
<weather>
  <header>
    <utemp>C</utemp>
  </header>
  <conditions>
    <temperature>22</temperature>
    <feelslike>19</feelslike>
  </conditions>
</weather>

Do transformacji użyjemy do tego dwóch plików XSL. Weather.xsl z prostym wzorcem XSL i Shared.xml w którym zdefiniowano zmienną przypisaną do jednostki miary temperatury (w naszych przypadku to stopnie Celcjusza).

06 lipca 2011

Wersja 1.0 Weather.com .NET client - czyli stabilizacja

Co nowego w wersji 1.0?


US Zip code


W wersji 1.0 dodałem wyszukiwanie pogody z pomocą kodu pocztowego USA. Przy okazji dowiedziałem się, że są dwa formaty tzw. US Zip Code. Jeden z nich to 5 cyfrowy kod pocztowy w formace #####, wspierany przez API Weather.com. Drugi natomiast to format ZIP+4 w formacie #####-####. Niestety usługa sieciowa Weather.com akceptuje tylko 5-digit US Zip Code. Poniżej przykład pobrania danych pogodowych z użyciem kodu pocztowego.

var client = new WeatherClient("[Partner Id here]", "[License Key here]");
USZipCode zipCode = new USZipCode("20037");
CurrentWeatherInfo conditions = client.GetCurrentConditions(zipCode);

Jak zmierzyć wydajność zapytania w MS SQL Server?

Dlaczego w ogóle warto mierzyć wydajność zapytania SQL?


Nie jeden raz zdarzyło mi się porównywać czasy wykonania dwóch różnych zapytań SQL które były rozwiązaniem jednego problemu. Nie zawsze w sposób jednoznaczny można określić, które z zapytań jest bardziej optymanlne.  W przypadku zapytań wykonywanych na instancji SQL Servera interesują nas następujące parametry
  • czas wykonania
  • ilość odczytów stron potrzebnych do wykonania zapytania
  • ilość zapisów (np. w bazie tempdb)
  • użycie czasu procesora 
Bardzo pomocnym zródłem danych do analizy wydajności zapytania będzie też sam plan wykonania zapytania. W tym poście skupię się na jednym zapytaniu do znanej bazy danych AdventureWorks dla MS SQL Server 2008 R2. Skrypty zawarte w tym poście działają na MS SQL Server w wersji 2008 i wyższej, aczkolwiek po małych przeróbkach powinny zadziałać na wersjach 2005 i 2000. Testy wydajności przeprowadzę na przykładowym zapytaniu obliczającym sumę wartości zamówień dla dostępnych kategorii produktów.

SELECT pc.Name Category, SUM(sod.LineTotal) CategoryTotal
   FROM Production.Product p
  INNER JOIN Production.ProductCategory pc
     ON p.ProductSubcategoryID = pc.ProductCategoryID
  INNER JOIN Sales.SalesOrderDetail sod
     ON sod.ProductID =  p.ProductID
  GROUP BY pc.Name
  ORDER BY Category

Pomiar czasu wykonania


Czas wykonania może zmieniać się drastycznie, w zależności od kilku czynników. Istotne jest, aby przed pomiarem czasu wykonania rozważyć kilka z następujących zagadnień:
  • czy jest to pierwsze wykonanie zapytania czy kolejne i dane zostały zaczytane do pamięcie SQL Servera?
  • czy serwer jest w dany momencie obciążony innymi operacjami (CPU, IO)?
  • czy dane uległy znaczącej zmianie i statystyki nie zostały zaktualizowane?
  • czy w cache'u znajduje się nieoptymalny plan wykonania dla danego zapytania?
  • czy zapytanie nie jest blokowane przez inne procesy w dostępie do zasobów (np. tabele)?