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.

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.

Ile razy zdarzyło się Wam zastanawiać, jak zadziała kawałek kodu w projekcie, nad którym właśnie pracujecie? I ile razy musieliście o taką informację (czyli – „jak to tak naprawdę zadziała”) oprzeć dalsze działania? Właśnie – mam wrażenie, że to jakieś niepisane tajemnicze prawo. W momencie gdy rozgrzebię projekt tak, że nic się nie kompiluje, lub gdy pracuję nad takim projektem, że żeby cokolwiek przetestować trzeba go 3 minuty konfigurować i uruchamiać – to właśnie staję przed podobnym dylematem. Jedynym sposobem na sprawdzenie kawałka kodu, który spowodował całe zamieszenia trzeba albo dodać nowy projekt, albo otworzyć kolejne VS z testowym projektem właśnie na takie okazje.

Od dziś zapomnijcie o podobnych – mrożących bity w bajtach – sytuacjach. Z pomocą przychodzi SnippetCompiler. To sprytne narzędzie przy uruchamianiu wita nas gotowym projektem typu ConsoleApplication, w którym możemy przetestować to, co nas trapi. Niesamowite ale posiada intellisense. Nie jest to oczywiście VisualStudio w wersji lite – nie spodziewajcie się zbyt wiele ;-) Czasem mam wrażenie, że jest napisany w Javie – tak potrafi się przyciąć ;-)

SnippetCompiler

Powiązane wpisy:

1. Przewodnik po polskich blogach poświęconych C# i .NET

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

Wybawieniem okazał się mały, opensource’owy programik Launchy.

Jak cudak wygląda? O proszę:

Launchy - okno główne

Odpalany jest domyślnie przy użyciu skrótu Alt+spacja. Bardzo intuicyjne i nie gryzie się z niczym innym w systemie. Konfiguracja startowa może być trochę uciążliwa – zawiera bowiem wszystko, co da się tylko odpalić z Menu Start -> Programy. Polecam jednak wgryźć się w Launchy, poświęcić 15 minut na dopasowanie go do własnych potrzeb – odpłaci się z nawiązką.

Co możemy w nim ustawić? Poza przezroczystością, skórką, czasem zanikania itp. najważniejsze to wskazanie katalogów, z których Launchy stworzy swoisty cache dla skrótów. Co ciekawe, mogą to być nie tylko pliki .exe, .lnk ale i adresy URL czy same foldery. Launchy zapamiętuje najczęściej uruchamiane opcje i po kilkunastu użyciach domyśli się, że gdy wpiszemy „f”, to w pierwszej kolejności możemy szukać „firefox’a”.

Konfiguracja Launchy

Polecam pobawić się, spróbować – co prawda nie ugryzie, ale sprawia jeden poważny problem – uzależnia ;-) Nie raz poczułem już zaskoczenie, gdy po naciśnięciu Ctrl+spacja na komputerze znajomego nie pojawiło się dobrze znane magiczne okienko ;)

Powiązane wpisy:

1. Łatwy zrzut ekranu – GadWin PrintScreen

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

Okno konfiguracji

Nie znaleziono powiązanych wpisów.

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