LogParser 2.2

Narzędzie do ściągnięcia w postaci MSI – tutaj.

Przypuśćmy, ze chcemy wyświetlić dane dotyczące nie odnalezienia strony przez naszą aplikację (czyli ze statusem odpowiedzi 404). Jednak aby ułatwić „eliminowanie problemu” pogrupujemy te dane wg URI o posortujemy po ilości wystąpień.

Musimy posiadać ID aplikacji w IIS. Wystarczy wejść w zaawansowane ustawienia witryny i sprawdzić jej identyfikator. W moim przypadku jest to ID = 5.
Pełna ścieżka do moich logów, to: C:\inetpub\logs\LogFiles\W3SVC5

Przenalizujmy plik z dzisiaj, polecenie z konsoli:

asdf

asp

fds

I wynik tej operacji:

asdf

asp

fds

Szerszy opis LogParsera choćby na wss.pl. Konsolowy LogParser może łatwo dać się upchnąć w narzędzia administracyjne, więc warto o nim pamiętać – zwłaszcza, że potrafi naprawdę sporo!

Indihiang

Indihiang to narzędzie GUI hostowane na codeplex. Pozwala na przeglądanie logów IIS oraz Apache w przyjaznej dla użytkowników formie wykresów, list etc.

Wskazujemy plik log, czekamy na jego przetworzenie:

I cieszymy oko wykresami podobnymi do:

Indihiang ma o wiele mniejsze możliwości niż LogParser. Jego przeznaczenie to po prostu możliwość szybkiej weryfikacji, czy w naszej aplikacji nie dzieje się coś złego. Do dogłębnej analizy logów LogParser nadaje się o wiele lepiej.

PS: jeśli masz system x64 koniecznie pobierz wersję x64! x86 płata figle!

A Wy – czego używacie do poglądania logów?

Powiązane wpisy:

1. Proste narzędzie do testowania zapytań XPath

Powiązane wpisy wygenerowane przez wtyczkę Yet Another Related Posts.

Program do pobrania: tutaj

Dla ciekawskich, realizacja poszukiwania XPath realizowana jest następującym kodem:

Powiązane wpisy:

1. Show-hide JavaScript – proste podłączenie przy użyciu C#

Powiązane wpisy wygenerowane przez wtyczkę Yet Another Related Posts.

I have spent numerous hours trying to translate error messages logged by application deployed at my Chinese client. After long hours of frustration, I finally found this site. So far, this site has saved me at least 1480 man hours of laborous searching for translations of those Chinese error messages. I simply love it!

jakże podobny do tego co odczuwamy tłumacząc na angielski polskie teksty wyjątków ;)

Teraz wystarczy wkleić tekst wyjątku do serwisu zamiast do google – to tylko jedno kliknięcie więcej ;)

W połączeniu z możliwościami jakie daje choćby Opera, wystarczy po krótkiej konfiguracji wpisywać w pasku adres np:

i serwis finderr zrobi za nas resztę ;)

Nie znaleziono powiązanych wpisów.

Powiązane wpisy wygenerowane przez wtyczkę Yet Another Related Posts.

Widać tam grupę ludzi angażujących się w pomoc innym, ciekawe pytania i rozważania. Co ważne – nie oderwane od naszego lokalnego podwórka. W informatyce wiele problemów jest „poza podziałami”, są jednak i takie dość mocno związane z konkretnym regionem. Devpytania stają się jednym z podstawowych serwisów, które odwiedzam. Pozwala mi to na zapoznanie się z problemami innych, i to problemami niekoniecznie dotyczącymi .NET czy nawet niekoniecznie programowania sensu stricte.

Do rzeczy jednak. Dlaczego wspominam o devpytania? Dlatego, że z pewnego tematu dotyczącego darmowych systemów typu bugtracker wziął się pośrednio pomysł na opowiastkę w odcinkach, której pierwszą część właśnie czytasz.

W odpowiedziach na wspomniane pytanie pojawiło się wiele odpowiedzi – wiadomo – każdy chwalił swoje. Osobiście od dość dawna używam systemu TRAC. Zaraził mnie nim jeszcze kolega ze studiów i używałem go już parę lat temu chyba na jedynej platformie w Polsce udostępniającej hosting SVN + TRAC – svn.pl. Zainteresował mnie natomiast inny – bugNET. Spróbować nie zaszkodzi. Zainstalowałem więc bugNET obok TRAC…

Pierwsze odczucie po instalacji – jest nieźle. Wszystko kolorowe, ikonkowe, błyszczące, świecące, grupujące się i radosne. W kolorze zielonym – ponoć kolor nadziei. Pozytywnie nastraja, jak na system który „śledzi” błędy. Marketingowo świetne ;)

Konfiguracja dość łatwa, wszystko odbywa się z poziomu przeglądaki. Nadszedł pierwszy zachwyt.
O zachwytach i samym korzystaniu jednak później. W tym odcinku skupię się na instalacji. Nie jest to sprawa, którą można zbagatelizować porównując TRAC i bugNET. Jest to diametralnie różne podejście i – moim zdaniem – nie bez znaczenia.

Ogólne założenia

Instalacja na systemie Windows, automatyczne uruchamianie z systemem i umożliwienie dostępu z zewnątrz.

Wymagana autoryzacja użytkowników.

Zakładamy, że zainstalowany jest SVN.

Punktacja w skali od 1 do 10, im więcej punktów przyznane tym lepsza ocena.

TRAC w wersji 0.11.6

BugNET w wersji 0.8.167.0 (RC2)

Może trochę niesprawiedliwie, że TRAC w wersji produkcyjnej a BugNET w wersji RC2, jednak kto powiedział, że świat  jest sprawiedliwy ;) ? Poważniej – BugNET „więcej daje” w wersji 0.8 a ewentualne bolączki wersji RC pominę w dalszych porównaniach.

TRAC

trac

Gdybyśmy instalowali TRAC na  Windows rok temu – to byłby dramat. Dokumentacja była dość uboga i co chwilę napotykane problemy sprawiały, że wszystkiego się odechciewało.

Obecnie nie jest to instalacja typu dalej-dalej-instalator-gadżeta ale każdy zainteresowany powinien sobie poradzić.

Kroki niezbędne do instalacji:

1. Instalacja Pythona (najlepiej wersja 2.5) – bezproblemowa. Plik MSI. 10/10
2. Instalacja TRAC – bezproblemowa. Instalator. 10/10
3. Instalacja Genshi – biblioteki do przetwarzania HTML / XML – bezproblemowa. Instalator. 10/10
4. Ściągnięcie ez-setup i umieszczenie w katalogu skrytpów. 10/10
5. Utworzenie projektu – z linii komend, używając skryptów. Uciążliwe ale nie dramatyczne. W sumie ogranicza się do „dalej-dalej” tyle że w lini poleceń. 7/10
6. Instalacja AccountManagerPlugin – do autoryzacji użytkowników. Z linii poleceń – ściągnięcie ze zdalnego repozytorium. Wszystko dzieje się samo. Do przeżycia. 7/10
7. Ustawienie sekcji w pliku konfiguracyjnym projektu i nadanie uprawnień anonimowemu użytkownikowi. Nie ma dramatu ale znowu konsola. 7/10
8. Uruchomienie TRAC z linii poleceń – proste, ale to chwilowe rozwiązanie. 7/10
9. Konfiguracja wtyczki uprawnień – już z poziomu przeglądarki. Wymaga dość intuicyjnego podejścia. 7/10
10. Ściągnięcie i zainstalowanie Windows Server 2003 Resource Toolkit – niezbędne do instalacji TRAC jako usługi systemowej. 9/10
11. Ustawienie TRAC jako usługi systemowej – trochę grzebania w rejestrze. Mimo, że dobrze udokumentowane to jednak uciążliwe. 3/10
12. Głęboki oddech i może zadziała ;) Za ilość kroków instalacj: 5/10

BugNET

bugNET

1. Założenie site’u na IIS. Dla niezaznajomionych może być kłopotliwe ale mocno udokumentowane – 9/10
2. Założenie bazy danych MS SQL. Raczej banalne. 9/10
3. Przerzucenie plików instalacyjnych do katalogu stworzonego website’u 10/10
4. Ustawienie ConnectionStringa do połączenia z bazą – 9/10
5. Uruchomienie skryptu instalacyjnego z przeglądarki. Informacja o statusie i ewentualnych błędach na ekranie. 10/10
6. Gotowe. Za ilość kroków instalacji: 10/10

Podsumowanie

Może najpierw numerkologia. Zaszalejemy ze średnią harmoniczną ;) ? Może nie – niech zostanie nic nie mówiąca średnia arytmetyczna. Jednak jak na poważne porównanie publikowane na poczytnym blogu przystało – cyferki muszą być ;) Poważniej:

TRAC. Ilość kroków instalacji – minimum 11. Średnia punktów 7,25.

BugNET. Ilość kroków instalacji – 5. Średnia punktów 9,50.

Dodatkowo TRAC wymaga „standalone servera” pracującego tylko na jego potrzeby. Dla bugNET można wykorzystać wbudowany IIS, jednak nie ma go np. WinXP Home.
TRAC zainstalujemy na każdym komputerze. BugNET tylko na Windows i tylko na takim, na którym można zainstalować IIS.

Wniosek:

Zdecydowanie łatwiej zainstalować jest bugNET niż TRAC, szczególnie dla zaznajomionych z zagadnieniami Windows i ASP.NET.
TRAC wymaga większej uwagi i może spowodować więcej nieprzewidzianych komplikacji, jednak da się go zainstalować wszędzie.

Odcinek wygrywa: BugNET

Powiązane wpisy:

1. Proste i przyjemne porównanie kolekcji w .NET
2. Polski klon stackoverflow.com – devpytania.pl

Powiązane wpisy wygenerowane przez wtyczkę Yet Another Related Posts.

Jest to duży plus, jednak często przydatna jest możliwość wykonania downgrade’u. Niedawno stanąłem właśnie przed taką koniecznością.

Udało mi się dotrzeć do tego wpisu, który zawierał również link do prostego programu wykonującego całą „brudną robotę” (do pobrania na końcu wpisu).

Konwertowałem dość proste solution z dwoma projektami (jeden typu class library i jeden typu windows forms application) – wszystko przebiegło bez żadnego problemu.

Wydawać by się mogło, że taki downgrade to skomplikowana sprawa. Jednak dzięki temu, że autor programu udostępnia kod konwertera, łatwo daje się zauważyć, że całe zagadnienie ogranicza się do dwóch niezbyt złożonych pętli – jednej to konwersji solution, drugiej do konwersji projektów się w nim znajdujących.

Konwersja solution

Wystarczy, że sprawdzimy każdą linię pliku .csproj i dokonamy odpowiednich zmian we wpisach „informacyjnych”:

Konwersja projektu
W ramach każdego projektu z solution wystarczy również dokonać niemal kosmetycznych zmian. Gdy spełniony jest poniższy warunek:

oraz zamienić:

na

… i to koniec.

Całość nie jest dość skomplikowana ale zapewne narzędzie pozwalające dokonać powyższych zmian przyda się prędzej czy później.

Nie znaleziono powiązanych wpisów.

Powiązane wpisy wygenerowane przez wtyczkę Yet Another Related Posts.