środa, 12 listopada 2008

Tip: Możesz wywołać breakpoint nie ustwiając go w IDE

Witam :-)
Pewnie 99% przypadków zatrzymywania kodu w tzw. breakpoincie dokonywana jest przez oznaczenie odpowiedniej linijki kodu jako właśnie breakpointa, klikając na marginesie edytora kodu Visual Studio w linii w której ma nastąpić przerwanie. Istnieje jednak inna możliwość jego wywołania: programowa. Wystarczy wywołać: Debugger.Break(). Wcześniej należy zaimportować przestrzeń nazw System.Diagnostics.

Pilnie kupię Windows Vista ;-)

Przygoda z Windows Azure była niczym sen, który pewnego wieczora (jakieś 5 min temu) prysnął. Jestem jeszcze przedpotopowym developerem pracującym na... XP-ku. Chyba czas iść do sklepu... ehhh.

niedziela, 9 listopada 2008

Democamp Poznań. Targi startupów.

20 listopada 2008 w Pawilonie nr. 11 Międzynarodowych Targów Poznańskich odbędzie się impreza "Democamp", czyli targi przeznaczone dla startupów. Na targach, oprócz projektów, zagoszczą także spółki Venture Capital oraz będziemy mogli poznać działalność akademickich inkubatorów przedsiębiorczości. Impreza obowiązkowa dla wszystkich, który chcą zaistnieć w sieci wraz ze swoim projektem!

Źródło: http://democamp.pl/

sobota, 8 listopada 2008

Inspektor Gadget, czyli śledzenie aplikacji cz. II

log4net wchodzi na scenę

Podstawowymi klasami biblioteki log4net z jakimi będzie pracował programista są: LogManager oraz Log. LogManager pełni funkcję kontentera i zarządcy nad Loggerami. Cały system może składać się z hierarchii Loggerów – klas dostarczających metod do logowania. Aby otrzymać konkretną nazwaną instancję klasy Logger posługujemy się statycznymi metodami GetLogger obiektu LoggerManager.



Żądania logowania wykonywane są przez wykonanie określonej metody w zależności od typu zaistniałego zdarzenia, czyli: DEBUG, INFO, WARN, ERROR, FATAL
Zdarzenie zostanie zalogowane przez dany Logger jeśli ma taki sam lub wyższy priorytet. Z kolei każdy Logger może posiadać filtr w którym określono na zdarzenia jakiego typu (priorytetu) ma reagować. Jeśli do danego Loggera nadejdzie żądanie zalogowania zdarzenia niższego niż jest przez niego obsługiwane, to nie zostanie ono zalogowane. Warto zauważyć także, że każdy typ logów może mieć określony sposób formatowania, jest to szczególnie istotne zwłaszcza jeśli część z nich wysyłamy np. mailem w formacie HTML, a część logujemy w bazie w postaci czystego tekstu.

Konfiguracja log4net
Żaden system bez odpowiedniej konfiguracji nie może działać poprawnie. Na szczęście log4net dostarcza szeroki wachlarz możliwości konfiguracji zarówno przez pliki XML jak i programowo. Po pierwsze musimy pobrać log4net z witryny http://logging.apache.org/log4net/download.html i dodać referencję do jego głównej biblioteki log4net.dll. W niniejszym przykładzie będę posługiwał się wersją 1.2.10. Sam log4net nie wymaga wielkiego nakładu na jego konfigurację aby zaczął działać w swojej podstawowej formie. W zasadzie można powiedzieć, że domyślne ustawienia środowiska są wystarczające, aby zacząć przygodę z log4net i sprawdzić, czy w ogóle jest to warte zachodu :-)

using System;
using System.Collections.Generic;

using log4net;
using log4net.Config;

namespace ConsoleApplication1
{
class Program
{
private static readonly ILog MyLogger = LogManager.GetLogger(typeof(Program));

static void Main(string[] args)
{
BasicConfigurator.Configure(); //konfiguracja podstawowa, bez pliku xml
MyLogger.Info("Aplikacja została uruchomiona");

}
}
}



Aby zmusić log4net do pobrania swojej konfiguracji z pliku konfiguracyjnego aplikacji, programista musi jedynie stworzyć odpowiednie wpisy konfiguracyjne oraz wymusić załadowania nastawów z pliku. Spróbujmy dodać plik App.config i wypełnić go podobnie jak na schemacie poniżej.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
</configSections>
<log4net>
<appender name="ConsoleAppender" type="log4net.Appender.ConsoleAppender" >
<layout type="log4net.Layout.PatternLayout">
<conversionPattern value="%date [%thread] %-5level %logger [%ndc] - %message%newline" />
</layout>
</appender>
<root>
<level value="INFO" />
<appender-ref ref="ConsoleAppender" />
</root>
</log4net>
</configuration>



Teraz wystarczy jedynie załadować konfigurację wywołując metodę XmlConfigurator.Configure();

Logujemy!

Stwórzmy prostą aplikację, która swoją konfigurację do logowania pobierze z pliku konfiguracyjnego aplikacji, a logi typu INFO oraz DEBUG umieszcza na konsoli. Pierwsze co musimy zrobić do dodać odpowiedni plik App.config. Ze względu na to, że w naszym systemie chcemy logować dwa typy zdarzeń: informacyjne (INFO) oraz debugowe (DEBUG) musimy stworzyć wpis appender, czyli naszego wyjścia. Wewnątrz wpisu appendera należy podać sposób formatowania pojedynczego wpisu logu.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
</configSections>
<log4net>
<appender name="ConsoleAppender" type="log4net.Appender.ConsoleAppender" >
<layout type="log4net.Layout.PatternLayout">
<conversionPattern value="%date [%thread] %-5level %logger [%ndc] - %message%newline" />
</layout>
</appender>
<root>
<level value="DEBUG" />
<appender-ref ref="ConsoleAppender" />
</root>
</log4net>
</configuration>



Dostępne w log4net wyjścia dla naszych logów to:
• AdoNetAppender,
• MS SQL Server,
• MS Access,
• Oracle9i,
• Oracle8i,
• IBM DB2,
• SQLite,
• AspNetTraceAppender,
• BufferingForwardingAppender,
• ColoredConsoleAppender,
• ConsoleAppender,
• EventLogAppender,
• FileAppender,
• ForwardingAppender,
• MemoryAppender,
• NetSendAppender,
• OutputDebugStringAppender,
• RemotingAppender,
• RollingFileAppender,
• SmtpAppender,
• SmtpPickupDirAppender,
• TraceAppender,
• UdpAppender

Uważny czytelnik zauważył pewnie, że nie zdefiniowaliśmy celu naszych logów dla zdarzeń INFO. Tak jak wspominałem wcześniej zdarzenia mają określoną hierarchię i w przypadku wystąpienia zdarzenia o priorytecie >= zdefiniowanemu zostanie on na pewno obsłużony, a o niższym priorytecie - nie.
Wpis o priorytecie INFO jest nad wpisem DEBUG więc wyląduje na naszej konsoli. Podobnie stanie się z wpisami o priorytetach ERROR i FATAL - te akurat zdarzenia powinny być umieszczane w blokach try-catch i automatycznie gromadzić wyjątki np. w bazie danych. Po dokładną specyfikację priorytetów odsyłam do oficjalnej strony projektu log4net .
W systemie może istnieć tyko jeden logger główny: root, reszta logerów dziedziczą po nim tworząc swoiste drzewo dziedziczenia.

namespace ConsoleApplication1
{
class Program
{
private static readonly ILog MyLogger = LogManager.GetLogger(typeof(Program));

static void Main(string[] args)
{
XmlConfigurator.Configure();
MyLogger.Info("Aplikacja została uruchomiona");
If (args != null)
MyLogger.Debug(string.Format("Argumenty uruchomieniowe: {0}", args));
MyLogger.Info("Aplikacja została zakończona");
}
}
}



Efekt powinien być podobny do tego:



W ten oto sposób poprawnie skonfigurowaliśmy oraz zalogowaliśmy pierwsze zdarzenia za pomocą biblioteki log4net! Chyba nie było to trudne?

Do pobrania:

Tip: Jak przyśpieszyć uruchamianie projektu?

Istnieje pewna sztuczka w Visual Studio, która pozwala za skrócenie czasu uruchamiania się i budowania projektów. Kiedy plik solution składa się z wielu projektów, wystarczy zaznaczyć, aby budowany był jedynie projekt startowy oraz jego zależności.
Tools – Options – Projects and Solutions – Build and Run i zaznaczamy Only build startup projects and dependencies on Run

czwartek, 6 listopada 2008

Inspektor Gadget, czyli śledzenie aplikacji cz. I

Problem śledzenia działania aplikacji oraz eliminowania błędów jest tak stary jak stare jest programowanie. Pierwsze języki programowania nie posiadały rozbudowanych środowisk programistycznych oraz tak zaawansowanych technik śledzenia wykonywania kodu programu. Wraz z rozwojem samych języków, rozwoju ulegały także zintegrowane środowiska wytwarzania oprogramowania. Dziś chyba trudno sobie wyobrazić programowanie, a tym bardziej wyłapywanie błędów bez debugera.
Chciałbym przyjrzeć się w jaki sposób możemy najefektywniej śledzić działanie aplikacji oraz wychwytywać w nich błędy. Wszystko po to, aby nasze programy mogły działać jeszcze szybciej i bezbłędnie.

Podejście pierwsze – najprostsze
Chyba każdy z nas stosował lub nawet stosuje do dziś popularne wyświetlanie zawartości interesujących nas zmiennych na ekranie (konsoli). Popularna technika jest chyba najstarszą formą debugowania programów. Jej podstawową zaletą jest to, że bardzo łatwo ją zaimplementować oraz daje przejrzyste wyniki. Na tym chyba zalety się kończą. Wad jest sporo: kod służący do śledzenia kompilowany jest to programu wynikowego, trudno w nim śledzić bardziej zaawansowane powiązania z innymi zmiennymi itd.

Na szczęście takie podejście do problemu śledzenia aplikacji należy raczej do rzadkości, a metodologie dostępne dla każdego programisty dają znacznie lepsze rezultaty. Innym pewnym rozwinięciem przedstawionej wyżej techniki jest zapis stanu zmiennych do pliku tekstowego. To również popularna technika ze względu na łatwość zapisu do pliku w większości języków programowania. W dalszej części artykułu postaram się je przedstawić w jaki sposób za pomocą dostępnych narzędzi i bibliotek możemy podejść do problemu w bardziej zaawansowany sposób.

Biblioteki logowania
Czym są biblioteki programowania? Są to specjalizowane biblioteki stworzone po to aby programista nie musiał przejmować się samym sposobem wyświetlania, czy zapisu komunikatów diagnostycznych. Praca z nimi zazwyczaj sprowadza się do wywołania odpowiedniej metody, a biblioteka sama dba o odpowiedni przepływ komunikatów diagnostycznych. Należy w tym momencie nadmienić, iż powstał pewien podział na komunikaty diagnostyczne, które zostały oddzielone od komunikatów błędów. Często prowadzi to do innego (definiowanego przez programistę) zachowania się bibliotek logowania w przypadku wystąpienia błędu, a innego w momencie rejestracji informacji czysto diagnostycznych.
W Internecie istnieje wiele bardzo dobrych rozwiązań służących do tego celu. Najciekawsze z nich to:
1. log4net
2. NLog
3. Microsoft Enterprise Library Logging Application Block

Pierwsza z przedstawionych bibliotek jest portem doskonałej javowej biblioteki log4j. Posiada ona bogatą grupę projektów, które z jej rozwiązań korzystają oraz - co jest zaletą – jest dość dojrzałym i stabilnym projektem. Nie ma najmniejszych problemów z dostosowaniem przepływu raportowania, a lista celów naszych logów jest długa.
NLog został stworzony przez polskiego programistę: Jarosława Kowalewskiego . Zawiera wiele celi logowania oraz pozwala na bardzo szeroką konfigurację. Niestety projekt nie jest już tak dynamicznie rozwijany – w zasadzie można powiedzieć o jego wstrzymaniu, choć na oficjalnej stronie takich informacji nie znajdziemy. Nie zmienia to faktu, iż w obecnej formie projekt pozwala na wykonanie wszystkich popularnych operacji zarówno raportowania błędów jaki i informowania o stanie aplikacji.
W kolejnych częsciach artykułów będę starał się przedstawić jak z tych dobrodziejstw korzystać. Zapraszam do odwiedzania!
Nich kod będzie za Wami!

niedziela, 2 listopada 2008

CodeGuru: Wykład pt. "ASP .NET Ajax"



Chciałbym wszystkich zaprosić na mój wykład, który odbędzie się 4 listopada 2008 r. na Politechnice Poznańskiej, a na którym będę starał się przedstawić wstęp do "ASP .NET Ajax". Spotkanie to odbywa się w ramach studenckich grup .Net.
Rejestracja na spotkanie jest możliwa przez portal CodeGuru.pl pod adresem: http://codeguru.pl/Default.aspx?Page=Events/ShowEventDetails&eventId=1814

Dodano: 04.11.2008
Przykłady oraz prezentacja (mirror na CodeGuru.pl):