Jedną z trudniejszą z rzeczy z jaką spotyka się każdy web developer jest dostosowanie działania witryny i jej optymalizacja wynikająca ze zróżnicowania dostępnych przeglądarek. Każdy spotka się prędzej czy później z piekłem przeglądarek wynikającym z ich wojny o rynek :-) Aktualny ranking firmy Gemius na temat popularności przeglądarek internetowych w naszym kraju przedstawia się następująco:
Do tego dochodzą różne konfiguracje wymienionych wyżej przeglądarek takie jak ustawienia javascript, flash, różne rozdzielczości ekranu itd.
Oto kilka przydatnych narzędzi w testowaniu witryn na wielu przeglądarkach i ich konfiguracjach, które zarazem nie zamienią naszego komputera w śmietnik.
Browsershots.org Robi zrzuty ekranowe podanego przez nas adresu www. Zalety: prostota, długa lista obsługiwanych przeglądarek Wady: czasami trzeba czekać na wyniki kilkanaście minut, witryna musi być dostępna publicznie, niektóre maszyny testujące potrafią się zawieszać. Dodatkowo w sieci istnieje wiele innych witryn o podobnym działaniu: np. komercyjny i rozbudowany CrossBrowserTesting.com.
Internet Explorer Application Compatibility VPC Image Zestaw obrazów VPC systemu operacyjnego WindowsXp wraz z zainstalowanymi przeglądarkami Internet Explorer w wersji 6, 7, 8 (do wyboru). Zalety: otrzymujemy podręczne środowisko testowe, Wady: trzeba mieć odpowiednie zasoby sprzętowe na uruchomienie kilku maszyn wirtualnych. VPC działają jeszcze do stycznia 2010 r.
Expression Web Super Preview Umożliwia podgląd wyrenderowanej witryny z poziomu programu Microsoft Expression Web. Zalety: zintegrowanie podglądu witryny z procesem tworzenia. Wady: wymagany Expression Web
Firefox IE View Wtyczka do przeglądarki Firefox umożliwiająca przełączanie silnika renderującego z/na Internet Explorer-a. Zalety: szybkość działania.
Spotkanie Poznańskiej Grupy Praktyków Agile odbędzie sie w siedzibie Cognifide
(Al.Wielkopolskie 4, Poznań) 6 października o godzinie 18:00.
Wojciech Buras poprowadzi prezentacje "TDD w prawdziwym swiecie",
podczas której omówione zostaną miedzy innymi następujące kwestie:
1. Najczęstsze problemy z przełożeniem designu na kod i testy.
2. Czym jest i czym nie jest TDD?
3. Przykład ewolucji designu z pomocą TDD.
4. Promowanie testowalności.
5. Zastosowanie na linii frontu.
Warto się wybrać!
Po konkretnej nieobecności w trybie online powracam do życia - z kolejnymi wpisami znanej treści, tym razem słów kilka o niezwykle użytecznym narzędziu: NDepend.
Czym jest owy NDepend? To narzędzie dla .NET, którego autorem jest Patrick Smacchia. Służy ono do badania i raportowania złożoności oraz jakości tworzonego kodu. Na chwilę obecną posiada 82 metryki wyświetlające bardzo szczegółowe dane. Dodatkowo generator raportów sprawiają, że nawet “nieprogramista” może ocenić w jakiej kondycji jest dostarczony mu kod – narzędzie wszechstronne oraz wręcz nieograniczone. Możliwość integracji z NAnt-em lub MSBuild-em dostarczają automatów do wykonywania tego wszystkiego o czym troszkę napisze za chwilę.
Zacznijmy od początku. Po uruchomieniu NDependa wskazujemy zestaw bibliotek, które chcemy poddać analizie. Nie mam nic mądrego pod ręką, dlatego posłużę się bibliotekami MbUnit.
Program od razu przystępuję do akcji, a oczom naszym ukazuje się dłuuugi raport.
I tak, na pierwszy rzut widzimy:
ilość instrukcji IL, ilość linii, kodu, (uwaga) pokrycie kodu przez komentarze, ilość klas, ilość typów itd. O ile niektóre z tych danych, z praktycznego punktu widzenia, możemy potraktować statystycznie, o tyle już np. zależności między samymi klasami, martwy kod, konwencje nazewnicze mogą być tym, czego właśnie szukamy.
Kto, kogo, gdzie…
Wspomniane zależności między modułami mogą być bardzo skomplikowane, przedzieranie się pomiędzy nimi za pomocą Reflectora często po kilkudziesięciu minutach powoduje odruch wymiotny na widok kolejnego “dziedzica”. Na szczęście NDepend jest w stanie to wszystko ogarnąć i mimo że kod nadal pozostaje zakręcony, to my w tym gąszczu powiązań dość szybko możemy dojść do celu.
Refaktoryzacja kodu z tym okienkiem staje się wiele prostsza. Często graf może wydawać się zbyt obszerny:
Na szczęście do dyspozycji mamy dodatkowe dokowalne okienko: Dependency Matrix:
Skóra węża?
Kolejnym bardzo interesującym widokiem jest okno Metrics. Przypomina ono nieco skórę węża (tak, widzę tam skórę węża :-) ), a ma za zadanie wykonanie rentgena naszego kodu: każda bryła w ogólności symbolizuje klasę, która to składa się z mniejszych kwadracików – naszych metod. Im metoda ma więcej linii kodu, tym kwadracik jest większy. Sczegółowość możemy zawężać przełącznikiem widniejącym u góry okienka, natomiast zbiorcze informacje widzimy w okienku Info.
CQL
To nie wszystko! NDepend posiada wbudowany interpreter języka zwanego CQL (Code Query Language). Dzięki niemu piszemy kwerendy zbliżone do języka SQL, które to pozwalają odpytywać się NDependa o interesujące nas dane o naszym kodzie.
Operator projekcji: SELECT
Operator informujący: WARN
Aby utworzyć kwerendę należy skorzystać z okna CQL Query Edition, które posiada wbudowane podpowiadanie składni z możliwością wizualnego modyfikowania jej parametrów:
Przykłady:
1. Wyświetl metody publiczne, które mają więcej niż 30 linii kodu:
SELECT METHODS WHERE NbLinesOfCode > 30 AND IsPublic
2. Wyświetl 10 najbardziej złożonych metod i uszereguj metody ze względu na ich złożoność:
SELECT TOP 10 METHODS ORDER BY CyclomaticComplexity
3. Moja konwencja nazewnicza zabrania nazywania pól statycznych zaczynających się od przedrostka m_ Ostrzeż mnie jeśli znajdziesz takie wystąpienia:
WARN IF Count > 0 IN SELECT FIELDS WHERE NameLike "^m_" AND IsStatic
Słowo końcowe
NDepend to naprawdę niezły kombajn, kilka godzin może okazać się niewystarczające, aby zgłębić możliwości jakie drzemią w tym narzędziu. Warto go poznać, gdyż może uratować nam skórę podczas następnej refaktoryzacji kodu.
