Wprowadzenie do ciągłej integracji.

Czym jest ciągła integracja? Myśle że to pojęcie najlepiej oddaje cytat Martina Fowlera:

Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly. This article is a quick overview of Continuous Integration summarizing the technique and its current usage. 

Ciągła integracja jest praktyką z inżynierii oprogramowania w której integracja projektu odbywa się regularnie i często.Każda integracja jest weryfikowana przez automatyczne budowanie projektu
(włącznie z testami).Takie działanie ma na celu wczesne wykrycie błędów i ich usunięcie w etapie implementacji.

Wpływ CI na funkcjonowanie projektu

1. Zmniejsza się ryzyko w projekcie – dzięki wdrożeniu continuous integration projekt jest pod ciągłą kontrolą i monitoringiem.

2. Minimalizuje się ilość czynności, które należy wykonać w ramach procesu- dzięki automatyzacji budowania oprogramowania i czynności
wdrożeniowych.

3. W projekcie zawsze mamy do czynienia z oprogramowaniem gotowym do wdrożenia – dzięki zastosowaniu continuous integration, zespół jest zobligowany do tworzenia projektu, który umożliwia jego wdrożenie w dowolnym momencie.

4. Osoby odpowiedzialne za projekt mogą samodzielnie zbadać postęp prac w projekcie – wymiernym wskaźnikiem, który określa postęp projektu, jest stan oprogramowania, które można wdrożyć.

5. Większa pewność w odniesieniu do produktu – continuous integration wymusza, aby wytwarzane oprogramowanie weryfikować pod kątem za-implementowanych funkcji.


Budowanie z ciągłą integracją

Aby opisać proces ciągłej integracji posłużę się przykładem:
Rozpoczynając pracę musimy pobrać aktualną wersje (poprzez check out) naszego projektu z repozytorium
na maszynę na której będziemy pracować (Jest ona określana jako Mainline)
Po czym wykonujemy swoje zadanie, wciąż pracując na lokalnej kopi.
Piszemy lub zmieniamy automatyczne testy. Często określa się to jako kod samo testujący. ( Popularne xUnity) Gdy już zakończymy pracę. Uruchamiamy automatyczne budowanie projektu
Czyli komplikujemy, linkujemy do pliku wykonywalnego i odpalamy automatyczne testy.
Jeśli budowanie i testy przebiegły pomyślnie to możemy mieć nadzieję że nasz kod jest dobry.
Teraz pora na udostępnienie naszego nowego kodu w repozytorium.
Aby tego dokonać musimy wpierw uaktualnić naszą kopię o kod który został umieszczony przez innych programistów podczas naszej pracy i przebudować cały projekt.
Jeśli zmiany innych programistów nie współgrają z moimi zmianami,
poprzez problemy w kompilacji lub testach to konieczne jest dokonanie poprawek.
Robimy to dopóki nie uzyskamy prawidłowo działającej kopi zsynchronizowanej z mainline.
Po tym można wykonać commit, ale nie kończy on naszej pracy.
Musimy jeszcze raz zbudować cały projekt, lecz tym razem na serwerze do intergracji ( zwykle jest to maszyna na której znajduje się także repozytorium).
Gdy operacja się powiedzie możemy uznać że zakończyliśmy naszą pracę.
Ta operacja może zostać wykonana ręcznie przez programiste lub automatycznie przez narzędzia do integracji. Zaletą CI jest szybkie wyłapywanie błędów integracji.
Jeśli zdarzy się konflikt pomiędzy dwoma programistami to zwykle jest on szybko wyłapywany przez drugiego z nich.

Szybki przykład błędu

Dwóch programistów szybko po sobie commituje - pierwszy wprowadził poprawki A,
a drugi o tym nie wiedział i zrobił poprawki B. Pierwszy robi builda tylko z A. Commit zostaje zatwierdzony.
Drugi robi builda z A+B i jeśli były jakieś konflikty to wykrywany jest błąd.

Nawet jeśli nie będzie konfliktów to i tak błędy są wykrywane bardzo szybko.
Środowisko ciągłej integracji nie pozwala na przetrzymywanie przez dłuższy czas wadliwej wersji projektu.
Dobry team powinien mieć wiele poprawnych buildów na dzień.
Od czasu do czasu mogą się pojawić złe, ale będą one szybko poprawiane.Serwerem integracji będziemy nazywać maszynę na której przeprowadza się ten proces.Zwykle jest to maszyna na której jest przechowywane repozytorium.


Praktyki Ciągłej integracji.

Utrzymanie jednego źródła repozytorium.

Projekty oprogramowania składają się często z wielu plików które muszą być dokładnie zorganizowane.
Nie jest wieć niespodzianką że przez lata rozwoju oprogramowania powstało wiele narzędzi do zarządzania zbiorami plików. (Source Code Managment tools, Version Control Systems) Podstawą jest wybranie dobrego systemu. Najbardziej znanym i darmowym systemem kontroli wersji jest subversion, następca bardzo popularnego CVS'a).

Wszystko co jest potrzebne do wykonania buildu powinno się znajdować w repozytorium.
Włącznie z skryptami testowymi, plikami konfiguracyjnymi, schematami bazy danych,skryptami instalacyjnymi
czy dodatkowymi bibliotekami.Podstawową zasadą jest podejście projektu z "dziewiczą" maszyną, pobranie plików z repozytorium i poprawne zbudowanie całego systemu. Tylko minimalna ilość plików powinna znajdować się na maszynie developera. Zazwyczaj są to duże pliki lub trudne do zainstalowania lub skonfigurowania np: Środowisko uruchomieniowe czy system bazodanowy.

Automatyzacja budowania projektu.

Tradycyjnie budowaniem nazywamy compilacje, likowanie i dodatkowe rzeczy potrzebne
do stworzenia wykonywalnego programu.
Przekształcenie źródeł w działający system może być często skomplikowanym procesem w skład którego wchodzi
kompilacja, przenoszenie plików, załadowywanie schematów do baz danych.
Jednakże wiele tych zadań może zostać zautomatyzowanych.
np za pomocą Ant'a czy Ruby.
Zdecydowana grupa programistów używa ide które mają w sobie zintegrowany Build managment Proces.
Może ona tylko i wyłącznie służyć do indywidualnej pracy programisty.
Wersja na serwerze powinna używać do budowania skryptów.
W przypadku pluginów do eclipse musimy użyć techniki zwanej headless build.
Dzięki narzędziu PDE(Plug-in Development Environment) możemy uruchamiać pluginy poza środowiskiem (IDE)

Automatyczne testy.

Automatyczne testy stosujemy by możliwie szybko i efektywnie
wyłapać pojawiające się błędy oprogramowania.
Możemy to zrobić poprzez dołączenie ich do procesu budowania całej aplikacji.
Testowanie nie jest idealne, ale pozwala nam na wyłapywanie wielu błędów.
Kod który jest zaopatrzony w procedury testujące nazywamy Self Testing Code.
Wynik działania testów powinien jawnie wskazywać błąd.
Rodzina XUnit jako zestaw oprogramowania do przeprowadzania testów.

Każdy commituje każdego dnia.

CI pozwala deweloperowi powiadomić innych o zmianach które dokonał.
Dzięki częstemu commitowi można szybko wykrywać konflikty pomiędzy dwoma programistami
Konflikty które zostają niewykryte przez dłuższy okres mogą być ciężkie do rozwiazania.
Faktem jest że updatując swoją wersję przed commitowaniem jej do repo możemy wyłapywać konflikty integracji z taką samą łatwością jak konflikty tekstowe.
Gdy build jest zaopatrzony w  procedury testujące możemy także wyłapywać konflikty w działającym kodzie. Czym częstsze commity tym więcej szans na wyłapanie konfliktów i szybsze ich usuwanie.
Częste udostępnianie kodu dzieli pracę programisty na małe kawałki.Przeszkodą w realizacji tego założenia jest przeświadczenie o tym że wciągu tych paru godzin nie można zrobić niczego sensownego.

Każdy commit powinien budować kod na serwerze do intergracji.

Dzięki codziennym commitom, budowanie i testowanie naszego projektu przeprowadzane jest wiele razy dziennie.Najważniejszym jest by po zakończeniu każdego etapu prac mainline zostawało w zdrowym stanie.
W praktyce często jest to bardzo trudne.
Powodem tego może być brak dyscypliny. Programiści nie wykonują update'a i builda przed commitem
lub mogą to być różnice środowiskowe pomiędzy maszynami deweloperów.

Jeśli budowanie na serwerze do integracji zostanie przeprowadzone pomyślnie i testy nie wykarzą błędów
to takiego commita możemy uznać za prawidłowego. W przeciwnym razie muszą zostać dokonane poprawki.

Budowanie mainline można zapewnić na dwa sposoby, manualnie i używając CI server.
Manualnie czyli identycznie jak na swojej maszynie.
Programista zrzuca head'a na integration serwer i wykonuje budowanie, dokładnie śledząc cały proces.
(podobne do wizyt w pokoju wielkiego brata)
Budowanie automatyczne z użyciem CI tools jest bardziej skomplikowane ale to ono jest częściej wykorzystywane Serwer CI działa wtedy jako monitor repozytorium. Po każdym zakończonym commicie zrzuca aktualną wersję na integration serwer , inicjalizuje budowanie, i zawiadamia programistę o rezultacie całego procesu. Praca programisty kończy się gdy ten dostaje pozytywną wiadomość zwrotną. Zazwyczaj w formie emaila.

Istnieje wiele narzędzi pełniących funkcje serwera integracji.
Do najpopularniejszych z nich możemy zaliczyć Cruise Control, Hudson, Continuum
Wiele instytucji robi regularne buildy w ściśle określonym czasie, np w nocy.Nie ma to nic wspólnego z buildami ciągłej integracji.Nocne budowanie sprawdza czy w kodzie nie znajdują się bugi które nie zostały wykryte podczas dnia. Jeśli zostaną one nie wykryte przez dłuższy czas ich usunięcie może być bardzo trudne.

Spraw by system budował się szybko.

Czas budowania ma kluczowe znaczenie.
Podczas procesu ciągłej integracji wykonuje się wiele commitów, a co za tym idzie wiele budowań.
Często można je znacznie skrócić eliminując tzw. wąskie gardła.
W rozbudowanych projektach często proces integracji spowalniany jest przez testy,
które pracują na zewnętrznych źródłach np bazie danych.
Próby przyspieszania budowania mogą pociągać za sobą spadek wykrywania błędów.
Ważnym jest aby osiągnąć pewien złoty środek w tej materii.
Najlepszym rozwiązaniem przyspieszającym budowanie projektu jest wprowadzenie tzw. "staged build"

a) Two Staged build. 

Pierwsza część wykonuje kompilacje i najbardziej zlokalizowane zestawy testów
czyli takie które nie dotyczą zewnętrznych źródeł.
Używa się jej w głównym cyklu CI np jako commit do repozytorium (Commit Build).
Druga cześć obejmuje wszystkie testy, włączając w to testy na bazie danych i
jest ona wywoływana tylko wtedy gdy istnieje taka potrzeba lub co jakiś czas.
Jeśli druga część znajdzie błąd to powinniśmy rozważyć dodanie do commit build (pierwsza część)
dodatkowy test który ten błąd wychwyci.
Dzięki temu ten błąd zostanie poprawiony w commit build.

b) Rozszerzenie Staged Build.

Podstawowa zasada 2 faz budowania może być rozszerzona do dowolnej liczby późniejszych budowań.
Budowania po commicie mogą być wykonywane równolegle np przez dwie maszyny dokonywujące po połowie testów.
Używając równoległych budowań 2 fazy można wprowadzić wiele automatycznych testów,
włączając w to testy wydajności,do
regularnego procesu budowania.

Testuj w środowisku jak najbardziej zbliżonym do produkcyjnego

Platforma testowa powinna być identyczna jak platforma na której piszemy oprogramowania.
Dotyczy to zarówno wersji oprogramowania, jak i rodzaju (np systemu,bazy danych).
Od tej reguły odchodzi się przypadku aplikacji desktopowych w których zależy nam na przenośności rozwiązań.
W takim przypadku oprócz klonu systemu zaleca się testowanie projektu w różnych środowiskach.
np wykorzystując wirtualizację.

Zapewnij wszystkim dostęp do najnowszego skompilowanego projektu.

W każdym momencie trwania projektu istnieje potrzeba jego uruchamiania do demonstracji,
testów badawczych, czy obserwowania zmian.
By ułatwić to zadanie należy jawnie określić ścieżkę w której można znaleźć aktualne pliki wykonywalne.
Użytecznym jest umieszczenie kilku ostatnich skompilowanych wersji projektu.


Każdy widzi co się zdarzyło.

Każdy możne łatwo przeglądać aktualny stan systemu oraz zmiany które zostały wdrożone.
Dotyczy to szczególnie informacji o stanie mainline.
W zaawansowanych systemach CI ( Cruise, Hudson ) wszystkie informacje są dostępne z poziomu przeglądarki.
Najważniejszą z nich jest obecny stan systemu często sygnalizowany w postaci czerownej i zielonej lampy.
Ponadto Cruise pozwala na sprawdzenie kto ostatnio budował projekt, jakie zmiany zostały w nim wprowadzone.
Udostępnia on historię zmian systemu znacząco ułatwiając pracę kierowników projektu.

Automatyzacja przenoszenia plików pomiędzy maszynami.

Do ciągłej integracji potrzebujemy wielu środowisk.
Jednego do uruchomienia testów commitu,
i jednego lub więcej by uruchomić drugie testy.
W związku z tym pliki wykonywalne muszą być przemieszczane wiele razy dziennie.
Tą czynność można także zautomatyzować.
Ważnym jest by posiadać skrypty które pozwolą na proste i
szybkie rozmieszczenie aplikacji pomiędzy środowiskami.

Korzyści z Ciągłej Integracji.

Ciągła integracja nie uwalnia nas od błędów, tylko sprawia że ich wykrywanie
i usuwanie jest szybsze i wygodniejsze.
Zmieniamy tylko mały kawałek systemu. W przypadku błędu nie musimy się cofać.
Możemy także użyć tzw Diff Debugging -
wykrywanie błędów poprzez porównanie obecnej wersji z poprzednią która jego nie zawierała.
W projektach w których zastosowano CI znacząco spada ilość błędów.
Wszystko jednak zależy od jakości zestawów testowych.

Zalety:

    Kiedy natchniemy się na błąd, programista może bardzo łatwo wrócić do 
    poprzedniej wersji projektu, wolnej od błędów, bez konieczności straty czasu na debugowanie.
    Problemy integracji są wykrywane i naprawiane w sposób ciągły.
    Szybkie ostrzeganie o zepsutym lub niekompatybilnym kodzie.
    Szybkie ostrzeganie o konfliktowych zmianach.
    Natychmiastowe testowanie wszystkich zmian
    Stała dostępność aktualnego buildu dla testowania, demonstracji lub wydania.
    Brak odrębnych sesji integracyjnych
    Poprawa pracy zespołowej
    Ciągła integracja to jedna z podstawowych praktyk Extreme Programming.

   
Od czego zacząć ?

Pierwszym krokiem w Ci jest zautomatyzowanie builda.
Umieść wszystko co potrzebujesz w do wykonania builda w systemie kontroli wersji
i spraw by build mógł się wykonywać po napisaniu jednej komendy.
Na początek można spróbować budować projekty na żądanie lub wykonać automatyczny nocny build.

Kolejnym krokiem będzie wprowadzenie automatycznych testów.
Spróbuj zidentyfikować główne miejsca w których mogą występować błędy i
napisz testy eksponujące te nieprawidłowości.Spróbuj przyspieszyć commit build.
Kiedy startujesz z nowym projektem to od razu wprowadź do niego ciągłą integrację.

Na podstawie:
"Continuous integration" by Paul Duvall

Więcej informacji w

http://en.wikipedia.org/wiki/Continuous_integration
http://oreilly.com/catalog/0636920016489

Eclipse 3.7 już jest !!

Już wczoraj na oficjalnej stronie eclipse pojawiła się najnowsza wersja platformy Eclipse opatrzona nazwą Indygo. W tej wersji zostały wydane aż 62 projekty w tym takie nowości jak Jabula, która jest podstawą dystrybucji do testowania aplikacji oraz dedykowanego produktu do frameworka Scout. Zachęcam do zapoznania się ze wszystkimi nowościami w ramach whats new oraz testów nowego Indygo. :]

Zainteresowanych odsyłam do bloga eclipse:
http://eclipsesource.com/blogs/2011/06/22/top-10-eclipse-indigo-features/

 Eclipse Graph Tools

Eclipse Graph Tools to kontynuacja projektu o którym pisałem w ramach tego posta. Jego celem jest stworzenie dynamicznie rozszerzalnej platformy pozwalającej na modelowanie grafów za pomocą narzędzi graficznych oraz prezentacja popularnych algorytmów grafowych bazujących na podanym modelu. Głównym celem projektu było stworzenie narzędzia które będzie zapewniało prosty sposób modelowania grafów w postaci:

1. Graficznej – za pomocą wbudowanego edytora grafów.
2. Tekstowej – za pośrednictwem popularnej notacji DOT używanej m. in. w narzędziu GraphViz.

Grafy stworzone w ramach takiej reprezentacji miały być przedstawione za pomocą prostego modelu który pozwalał by na przetwarzanie go w ramach dowolnego algorytmu grafowego.
Model ten powinien być na tyle ogólny by pozwolić na ewentualne rozszerzenia: 

Projekt składa się z 3 niezależnych komponentów.

1. Narzędzie do modelowania grafów oraz edytor modelu grafu
   Początek pracy z programem zaczynamy od wizardu dostępnego w menu File >> New >> Other >> EGT
   
   
   
   
   

W ten sposób powstają 2 pliki. Jeden odpowiadający za graficzną reprezentacje grafu (modeler grafu) oraz plik modelu, który domyślnie otwiera edtor pozwalający na podgląd grafu.

Modeler grafu:

Edytor modelu grafu:

2. EDT Core i Visualization plugins

Pluginy core oraz visualization są osobną częścią programu odpowiadającą za komunikacje pomiędzy modelem a algorytmami napisanymi przez zewnętrznych użytkowników.

Aby uruchomić mechanizm wizualizacji w modelerze grafu otwieramy menu kontekstowe i wybieramy opcje "Apply Algorithm".

W nowym oknie wybieramy interesujący nas algorytm oraz sposób wykonywania kolejnych kroków: Krokowy lub Czasowy:

Po wybraniu algorytmu przechodzimy do jego wizualizacji. Poprzez wykonanie kolejnych kroków widzimy przebieg algorytmu na grafie odpowiadającym modelowi. Obecna wersja wspiera tylko model wizualny. Do zaimplementowania pozostała wizualizacja modelu opisanego za pomocą specyfikacji .DOT.

3. Zestaw przykładowych algorytmów wraz z API.

Program został napisany w sposób który maksymalnie upraszcza tworzenie nowych roszrzerzeń algorytmów. Dodatkowo wraz z programem został dołączony oddzielny plugin który zawiera przykładowe implementacje prostych algorytmów. Proces tworzenia nowego algorytmu wymaga utworzenia rozszerzenia zwanego Extension dla dowolnego pluginu Eclipse. Musimy rozszerzyć Extension Point o nazwie pl.zgora.uz.egt.core.algoritm. W ramach rozszerzenia dodajemy nowy element który określa nasz algorytm. Pojedyńczy opis algorytmu w naprostszej wersji zawiera jego nazwe oraz klase która domyślnie implementuje interfejs pl.zgora.uz.egt.core.algoritm.GraphAlgorithm.

Poniższy kod obrazuje przykład implementacji takiego algorytmu:

public class DFS implements GraphAlgorithm {

private GraphModel model;

private GraphNotifier notifier;

private EList<Vertex> vertexes;

protected boolean[] isVertexVisited;

public DFS() {

}

public boolean run() {

prepareAlgoritm();

for (int i = 0; i < vertexes.size(); i++) {

if (vertexes.get(i).getColor().equals(Colors.CLEAN)) {

    vertexes.get(i).setColor(Colors.PERFORMED);

    dfsRun(i);}

}

return true;

}

private void prepareAlgoritm() {

  vertexes = model.getVertexes();

  for (int i = 0; i < vertexes.size(); i++) {

     vertexes.get(i).setColor(Colors.CLEAN);

  }

  isVertexVisited = new boolean[vertexes.size()];

  for (int i = 0; i < vertexes.size(); i++) {

     isVertexVisited[i] = false;

  }

}

public void dfsRun(int start) {

  addVertex(start);

  for (int i = 0; i < vertexes.size(); i++) {

   EList<Edge> edges = vertexes.get(start).getEdges();

  for (Edge e : edges) {

    int index = e.getParentVertex().getIndex();

    if ((isVertexVisited[index] == false)) {

    isVertexVisited[index] = true;

    dfsRun(i);

    }

   }

  }

  postProcess(start);

}

protected void postProcess(int x) {

   Vertex vertex2 = vertexes.get(x);

   vertex2.setColor(Colors.TOUCHED);

   notifier.notifyInputChanged(model);

}

private void addVertex(int position) {

   Vertex vertex2 = vertexes.get(position);

   vertex2.setColor(Colors.PERFORMED);

   notifier.notifyInputChanged(model);

}

public void init(GraphModel model, GraphNotifier notifier) {

  this.model = model;

  this.notifier = notifier;

}

}

Algorytm operue na modelu. Każda jego zmiana wymaga polecenia notifier.notifyInputChanged(model) gdzie model jest głównym elementem modelu (instancją GraphModel). Jest to niewątpliwą wadą tego mechanizmu. Kolejna wersja będzie bazowała na klasach nasłuchujących zmiany w modelu, co nie będzie wymagało bezpośrednich wywołań od strony klientów.

Dalsze plany rozwojowe.

Projekt jest jeszcze we wczesnym stadium rozwoju. Obecna wersja pozwala na modelowanie grafów oraz wizualizacje algorytmów Dijkstry, BFS i DFS. Poniżej lista zmian jakie zostaną wprowadzone w kolejnych wersjach:

1. Integracja projektu ze specyfikacją .dot
   http://marketplace.eclipse.org/content/graphviz-dot-zest-dot4zest
   Zamimpelemtowanie edytora dla .dot we frameworku xtext.
2. Poprawienie mechanizmu komunikacji pomiędzy algorytmem a jego reprezentacją graficzną. Rozszerzanie powinno bazować na klasie abstrakcyjnej a nie na interfejsie.
   Dodatkowo należy rozwinąć sam extension point o definiowanie własnych zestawów, ikon, dodatkowych kolorów, oraz typów wyświetlanych diagramów.
3. Zaimplementowanie nowych algorytmów grafowych.
   
   EGT jest projektem open source (licencja EPL). Jego kod źródłowy zostanie wkrótce opublikowany w ramach google projects. Jeśli jesteś zainteresowany współtworzeniem tego projektu to proszę o kontakt :]
   
   

Kalkulatorów ciąg dalszy...

"Czasem trzeba napisać coś do czego nie jesteśmy zbytnio przekonani" - z tą sentencją zabrałem się za napisanie krótkiego programiku na potrzeby laboratorium z modelowania w jezyku UML. To typowy program "do szuflady", wiec mam nadzieje że kod źródłowy przyda się przy niejednym zaliczeniu ;)

Zadaniem programu jest parsowanie podanego wyrażenia algebraicznego (obsługa nawiasów, potęgowania oraz podstawowych operacji arytmetycznych) do postaci drzewa rozbioru oraz generacja kodu asemblerowego na podstawie tego drzewa. Generowany kod może być edytowany(podświetlanie składni asm x86) oraz zapisany. Szczerze mówiąc nie jestem pewien poprawności generowanego kodu, gdyż ta część interesowała mnie najmniej.

  

Link do programu wraz ze źródłami

Kalkulator walut - online

Opis

Program służy do pobierana aktualnych kursów średnich wymiany walut,wykorzystując dane pobierane ze strony nbp.pl

Wymagania

1. Aktywne połączenie z internetem.
2. Środowisko urochomieniowe Java (JRE) w wersji 5 lub wyższej.
3. Lokalizacja plików binarnych środowiska JRE powinna być dodana do zmiennej systemowej path.
4. System operacyjny Windows. (Brak kontrolek dla innych systemów)

Elementy interfejsu.

Przykład zastosowania

1. Po uruchomieniu aplikacji przejdz do listy walut obcych.
2. Znaznacz interesujące waluty. Możesz to robić pojedyńczo bądz grupowo.
   (dla wielu przytrzymaj klawisz ctr lub shift) .
3. Naciśnij przycisk Dodaj aby dodać znaznaczone elementy.
4. Możesz zarządzać dodanymi elementami poprzez zmiane ich kolejności lub usuwanie poprzez przyciski zlokalizowane w prawym dolnym rogu aplikacji.
5. Przejdz do Menu głównego i wybierz Export.
6. Określ lokacje pliku tesktowego w którym będą przetrzymywane wybrane kursy walut.

Dowload 

http://wyslijto.pl/plik/j7zimfunf2

Eclipse Graph. Algorytmy grafowe w Eclipse Cz.1

Opis

Plugin Graph Toolbox jest prostym narzędziem służącym do modelowania grafów w środowisku Eclipse.
Jego głównym celem jest prezentacja działania prostych algorytmów grafowych.

Po zainstalowaniu plug-inu należy utworzyć nowy model wybierając File >> New >> Graph Toolbox >> New Graph

Funkcje: 

• Reprezentacja oraz edycje grafu w postaci tablicowej (edytor). 
• Transformacje oraz edycje do postaci macierzowej (dialog). 
• Przeszukiwanie wszerz i wgłąb. 
• Sortowanie topologiczne. 
• Wykrywanie cyklu 
• Wykrywanie silnych spójnych składowych (Algorytm Gabowa). 

Do zaimplementowania:

•  Reprezentacja graficzna grafu oraz prezentacja działania powyższych algorytmów.
•  Dodatkowe algorytmy: Algorytm Djikstry, Cykle Eulera...

 Screeny:

Dowload:

http://wyslijto.pl/files/download/myfpat7zw9

Ant Toolbox: Ant Task with Eclipse Api.

W ramach tego krótkiego wpisu postaram się omówić tworzenie własnego zadania, wykorzystywanego w narzędziu Apache ANT. W internecie aż kipi od tutoriali omawiających tworzenie własnych tasków dla narzędzia ANT. Nie mniej jednak większość z nich jest nieaktualna, bądź mało szczegółowa, szczególnie jeśli chodzi o współpracę z API Eclipse.

1. Po co nam własne zadania.

Ant jako narzędzie do budowania definiuje serie tasków które odpowiadają za podstawowe zadania związane z budowaniem i wdrażaniem oprogramowania. Wśród dostępnych zadań możemy znaleźć te typowe, służące do kopiowania zasobów, czy kompilacji, podpisywania jarów itp. (lista taksów dostępna jest pod adresem ) Nie mniej jednak domyślny zasób tasków anta może być niewystarczający do bardziej zaawansowanych rozwiązań, takich jak np budowanie pluginów Eclipse. Z pomocą w tym wypadku przychodzi dodatkowa biblioteka o nazwie Ant contrib, która dostarcza dodatkowe taski, które znacząco ułatwiają tworzenie skryptów (np: Budowanie warunkowe z użyciem if, regexpy itp). Jeśli mimo tego twój skrypt zawiera pewne niedoskonałości lub uproszczenia to należało by rozważyć możliwość stworzenia własnego zadania.


2. Wymagania
Eclipse wraz z pluginem org.apache.ant.
(Testowane na dystrybucji Eclipse PDE 3.6.2)

3. Task formatujący lokalizacje
W tutorialu tworzymy task który sformatuje lokalizacje usuwając znaki przejścia do katalogów wyższych. Standardowo ant posiada taki mechanizm (http://ant.apache.org/manual/Tasks/property.html) jednak jest to dobry przykład wykorzystania tasków w połączeniu z platformą Eclipse.
Kod klasy obsługującej zadanie prezentuje się następująco:

import org.apache.tools.ant.BuildException;
import org.apache.tools.ant.Project;
import org.apache.tools.ant.Task;
import org.eclipse.core.runtime.IPath;
import org.eclipse.core.runtime.Path;


public class NormalizePath extends Task  {

 AntLogAdapter fLogAdapter;
 private String fDir = "";
 private String fSkipPoints="1";
 protected String fResultProperty="";
 
 
 /**
  * String represents dir locations for example C:/temp/data 
  * @param baseDir
  */
 public void setDir(String baseDir) {
  this.fDir = baseDir;
 }
 /**
  * Used to set return property. This property should have url like C:/temp/
  * @param property
  */
 public void setProperty(String property) {
  this.fResultProperty=property;
 }
 /**
  * Number of segments to skip
  * @param fSkipPoints
  */
 public void setSegments(String fSkipPoints) {
  this.fSkipPoints = fSkipPoints;
 }
 
 public void execute() throws BuildException {
  try {
   fLogAdapter=new AntLogAdapter(this);
   validateAtributes();
   generateResult();
   fLogAdapter=new AntLogAdapter(null);
  } catch (Exception e) {
   throw new BuildException(e.getMessage().toString());
  }
 }

 private void validateAtributes() {
  if(fDir.length()==0){
     throw new BuildException("Dir must be specified using the dir attribute");
  } else if(fResultProperty.length()==0){
    throw new BuildException("Property must be specified using the property attribute.");
  }
 }
 
 public void generateResult() {
  IPath path=new Path(fDir);
  Integer segmentsToRemove = Integer.valueOf(fSkipPoints);
  IPath finalPath = path.removeLastSegments(segmentsToRemove);
  if(getProject() !=null){
   getProject().setProperty(fResultProperty, finalPath.toOSString());
  }
 }

 @Override
 public String getTaskType() {
  return "normalize.path";
 }
 
}

Zadanie ma na celu usunięcie części segmentów z adresu URI wprowadzonego jako paramter.
Pola typu string oznaczają parametry wejściowe. Najważniejszym elementem klasy jest funkcja execute, która waliduje oraz usuwa segmenty.
Parametry wejściowe zadania to:

 lokalizacja - reprezentowana poprzez zmienną fDir.
 ilość segmentów do usunięcia - fSkipPoints
 nazwa zmiennej zwracającej wynik  fResultProperty


Aby przetestować klasę musimy utworzyć obiekt pośredni który udostępni nam środowisko testowe przypominające wywołanie tasku poprzez anta:

import org.apache.tools.ant.Project;

import pl.com.astec.mdt.ant.tasks.NormalizePath;

public class NormalizePathMock extends NormalizePath{
 
 private Project tempProject;

 @Override
 public Project getProject() {
  if(tempProject==null)
   tempProject = new Project();
  return tempProject;
 }
 
 public String getResult() {
  if(tempProject!=null && fResultProperty!=null){
   return tempProject.getProperty(fResultProperty);
  }
  return "";
 }
}

Na sam koniec prosta klasa testowa stanowiąca przykład wykorzystania zadania

public class NormalizePathTest {
 
 NormalizePathMock task=new NormalizePathMock();
 
 @Test
 public void testGenerateResult() {
  String baseDir = "C://temp/testdir/removed_folder";
  Path expected=new Path("C://temp/testdir");
  
  task.setDir(baseDir);
  task.setProperty("test");
  task.generateResult();
  
  Path actual=new Path(task.getResult());
  Assert.assertTrue(actual.equals(expected));
 }
}

Ecliballs - Kulki w Eclipse

W ramach nauki biblioteki Eclipse EMF powstał projekt Ecliballs pozwalający na grę w uproszczoną wersje popularnych kulek. Plugin działa na wszystkich wersjach Eclipse z rodziny 3.x
Aby uruchomić grę należy przejść do dialogu Show view (alt+shift+q,q) i wybrać element Ecliballs umieszczony w kategorii Games. Komentarze mile widziane.

W przyszłości chciałbym wprowadzić:

•  bardziej rozbudowaną logikę gry (blokowanie kulek, czas gry itp),
•  nasłuchiwanie preferencji tak aby ustawienia były aktualizowane automatycznie,
•  usprawnienie grafiki. (integracja z draw2d).
• zapisywanie modelu po zamknięciu widoku/eclipse, 

Instalacja wymaga rozpakowania folderu oraz użycia standardowego mechanizmu instalacji Eclipse
(Help > Install new software).

Link: ecliballs.zip lub ecliballs.zip lub ecliballs.zip lub ecliballs.zip

Ustawienia kontekstu dla Apache Tomcat

1. Wprowadzenie
Poniższy post ma za zadanie objaśnić specyfikę działania kontekstów dla aplikacji uruchamianych w ramach kontenera Tomcat. Do zarządzania projektami wdrożonymi na serwer tomcat będziemy wykorzystywać niestandardowy plugin Eclipse o nazwie Sysdeo Eclipse Tomcat Launcher: http://www.eclipsetotale.com/tomcatPlugin.html. Pozwala on m.in. na automatyczne uruchamianie serwera w trybie debug oraz wdrażanie bez konieczności bezpośredniego kopiowania projektów.
2. Czym jest kontekst aplikacji 
Kontekst jest elementem reprezentującym aplikacje webową, która działa w ramach określonego wirtualnego hosta. Każda aplikacja wdrożona na serwer tomcat musi być rozpoznawana poprzez odpowiedni adres URL, którego końcówka przyjmuje zazwyczaj nazwę aplikacji np: http://localhost:8080/my_app

Więcej informacji o kontekstach na stronie: http://tomcat.apache.org/tomcat-4.0-doc/config/context.html

Apache Tomcat pozwala na dwa rodzaje wdrożeń aplikacji. Pierwszą z nich jest wdrożenie poprzez umieszczenie projektu w postaci pliku war do katalogu CATALINA_BASE/webapps. Po "wychwyceniu" nowego pliku tomcat rozpakuje jego zawartość do katalogu odpowiadającego nazwie pliku oraz tworzy kontekst wykorzystując element DefaultContext  (http://tomcat.apache.org/tomcat-4.0-doc/config/defaultcontext.html) w pliku server.xml. Standardowo Tomcat nie posiada elementu DefaultContex, a wszystkie wdrożone aplikacje przyjmują kontekst domyślny odpowiadający ich nazwie. Drugim sposobem na wdrożenie aplikacji jest jawne zdefiniowanie kontekstu przy pomocy pliku xml opisującego kontekst aplikacji. Plik powinien być umieszczony w katalogu CATALINA_BASE/webapps lub CATALINA_BASE\conf\Catalina\localhost. Przykładowo:
W tym przypadku aplikacja będzie dostępna pod adresem. http://localhost:8080/test. Kod źródłowy nie będzie wdrażany bezpośrednio do katalogu serwera, lecz pobierany bezpośrednio z workspace Eclipse
3. Metody pozwalające na usunięcie kontekstu
Aby odwoływać się do aplikacji poprzez adres pozbawiony części odpowiadającej za kontekst należy zdefiniować kontekst aplikacji jako /ROOT.
Dzięki temu wszystkie strony oraz serwlety będą dostępne bezpośrednio pod adresem http://localhost:8080. Definicja takiego kontekstu przysłoni standardową stronę serwera Tomcat. W przypadku gdy korzystamy z pluginu Eclipse Tomcat Launcher mamy możliwość podania nazwy kontekstu bezpośrednio w wizardzie nowego projektu. Zmiana ustawień dla istniejących projektów opiera się na edycji pliku .tomcatplugin znajdującego się w katalogu głównym.

    /
    false
    true
    false
    true
    
    
    /ROOT

Po edycji pliku należy zaktualizować kontekst poprzez wywołanie komendy Tomcat Project >> Update this context definition w menu kontekstowym projektu. Wprowadzone zmiany wymagają restartu serwera. Ustawienia zostały przetestowane dla Tomcata w wersji 6.