Eclipse Demo Camp we Wrocławiu (edycja druga)

Już za kilka dni odbędzie się druga wrocławska edycja Eclipse Demo Camp.



Interesujesz się środowiskiem Eclipse? Chciałbyś się dowiedzieć jak wykorzystać Eclipse nie tylko do programowania w Javie? Zapraszamy na spotkanie użytkowników i deweloperów środowiska Eclipse.

Eclipse DemoCamp Wrocław 2009!

  • Jacek Pospychała, JavaScript, AJAX w Eclipse

  • Jacek Laskowski, Enterprise JavaBeans (EJB) na OSGi

  • Krzysztof Kowalczyk, Transformacje Model-Model i Model-Text z wykorzystaniem technologii Eclipse

  • Grzegorz Białek, Tworzenie narzędzi w środowisku Eclipse (podstawy i nie tylko)


Rejestracja możliwa jest pod adresem:
http://oiola.com/e/496-druga-wroclawska-edycja-eclipse-demo-camp/


Więcej informacji o prezentacjach oraz prowadzących można znaleźć pod adresem: http://wiki.eclipse.org/Eclipse_DemoCamps_November_2009/Wroclaw

Spotkanie odbędzie się w sobotę 21 listopada 2009 w budynku firmy Sygnity (ul. Strzegomska 140. Sponsorem głównym została forma PB Polsoft




Zdjęcia oraz podsumowanie pierwszej wrocławskiej edycji Eclipse Demo Camp można znaleźć tutaj tu: http://deepdiveinto.blogspot.com/2008/11/pierwsza-edycja-eclipse-democamp-we.html

Tekstowe języki specjalizowane – prezentacja

Od pewnego czasu staram się promować na blogu idee tekstowych języków specjalizowanych a dokładnie technologię xText. Nie mogę więc nie wspomnieć o bardzo ciekawej webowej prezentacji jaka zakończyła się dosłownie kilka minut temu. Polecam ją każdemu, niezależnie od tego czy zajmuje się technologiami modelowania czy dopiero planuje się nimi zainteresować.



Podczas prezentacji oprócz naprawdę fajnego demka z szachami wyjaśniona została także architektura samego projektu. Przyznam że bardzo podoba mi się zastosowanie Google Guice jako sposobu na kastomizację generatów. Łączenie kodu generowanego z ręcznie pisanym zawsze stanowiło duży problem w projektach o większym stopniu złożoności niezależnie od zastosowanego podejścia. Zwykle kończyło się to albo dziesiątkami metod 'generated NOT' albo było skrajnie niewygodne jak modyfikacje w 'GMFGen' lub 'zastępowanie szablonów'. Szczególnie problem widoczny jest właśnie w przypadku biblioteki GMF która generuje naprawdę złożony kod który należy w dużej mierze zmodyfikować. Zastosowanie technologii Guice pozwala na znaczne rozluźnienie relacji pomiędzy poszczególnymi fragmentami budowanego edytora co znacznie upraszcza proces jego kastomizacji.

Bardzo ciekawy jest także dalszy kierunek rozwoju. Tematem przewodnim jest budowanie złożonych projektów opartych o wiele współpracujących modeli czyli koncepcja budowy indeksu modeli (instancji) w ramach środowiska. Rejestr modeli to jedno z pierwszych zadań jakie musi wykonać każdy projektant tworzący IDE. Ponieważ użytkownicy będą tworzyli dziesiątki lub setki instancji modeli w ramach projektu indeksowanie jest konieczne by wzajemnie się one widziały i możliwe były akcje typu wyszukanie czy refaktoring. Ustandaryzowanie tego typu mechanizmów może być kamieniem milowym w kierunku uniwersalnych mechanizmów refaktoringu (połączenie koncepcji index + compare)

Drugim tematem jest budowa tzw. języka bazowego dla reprezentacji wyrażeń. W każdym środowisku tworzymy lub wykorzystujemy jakiś istniejący język wyrażeń by wiązać poszczególne elementy modelu, reprezentować warunki etc. Czy jest to popularny XPATH, kolejna mutacja OCL czy cokolwiek innego mocno zależy to od wymagań tworzonego środowiska. Uproszczenie tego tematu wydaje się być atrakcyjne ale nie jestem pewien czy jest ono konieczne. Mamy już kilka modeli wyrażeń a pomimo tego każdy i tak tworzy własny by najlepiej odpowiadał potrzebom danego systemu. Nie do końca jestem przekonany czy powstanie kolejnego języka (bazowego?) cokolwiek wniesie do tematu. Przyznam że bardziej wolałbym gdyby połączono i dopracowano istniejące języki tak by powstała jedna składnia OCL’a, pojedyncza wersja XPAND’a etc. Możliwe jednak że źle rozumiem kierunek tego podprojektu. Czas więc poszukać dodatkowych informacji co i jak.

XText bez wątpienia wprowadza do środowiska Eclipse co najmniej tak dużo nowych możliwości jak kilka lat temu zrobił to GMF. Gdy tylko skończę czytać kupioną niedawno książkę o GMF biorę się za naukę. Mam nadzieję że analiza tego projektu pozwoli mi rozwiązać także problemy w moim własnym projekcie (koncepcja zastosowania Guice etc.)

8 lat w Java, 5 lat z Eclipse, 2 lata blogowania…

To straszne jak ten czas szybko płynie. Osiem lat temu w lipcu rozpoczynałem swoją pierwszą pracę. Język Java wydawał mi się wtedy totalnym nieporozumieniem. Borland JBuilder 4 nie dość że nie potrafił poprawnie zatrzymywać się na wszystkich break pointach to dodatkowo działał nieprawdopodobnie wolno na procesorach 300MHz :)

Z czasem bardzo polubiłem prostotę Javy jednak prawdziwym przełomem było pojawienie się środowiska Eclipse 2.1. Hierarchia wywołań metod, refaktoring, natywny wygląd i niewiarygodna szybkość porównywalna praktycznie z VisualStudio... to była rewolucja. Dzięki książkom 'Eclipse In Action' oraz 'Contributing to Eclipse' dowiedziałem się ponadto że można łatwo samemu robić dodatki do tego środowiska. To było wielkie odkrycie. Możliwe stało się coś co wydawało się być wcześniej zarezerwowane dla programistów wielkich zachodnich firm. Trochę ponad rok później miałem gotowe pierwsze narzędzia do modelowanie procesów sterowania centralami cyfrowymi zbudowane z wykorzystaniem biblioteki GEF (Graphical Editing Framework). To był początek wielkiej przygody.

Dwa lata temu postanowiłem założyć bloga. Celem jaki sobie postawiłem to zainteresować większą ilość osób tematyką Eclipse, a w szczególności ideą tworzeniu narzędzi specjalizowanych DSL (języków specyficznych dla rozwiązywanego problemu). Początki były naprawdę trudne, jednak miniony rok okazał się zdecydowanie lepszy. Głównie dzięki pomocy wielu osób związanych z grupami użytkowników języka Java (JUG) oraz serii konferencji Eclipse DemoCamp (między innymi organizacji pierwszej edycji wrocławskiej). Liczba odwiedzających ten adres zdecydowanie się zwiększyła co jest bardzo miłe.

W tym roku udało mi się także zdobyć licencję PADI Open Water Diver co w kontekście nazwy tego bloga ma kluczowe znaczenie. Sam egzamin przy zatoce znanej z filmu 'Niebiańska plaża' pozostanie jednym z najpiękniejszych wspomnień, podobnie jak cała wyprawa do Tajlandii. Mam nadzieję że kolejnym krokiem będzie nauka robienia zdjęć podwodnych. W tematyce programowania natomiast zabieram się za naukę technologii xText. Jest to bez wątpienia jeden z najbardziej innowacyjnych projektów na jaki trafiłem. We wrześniu planuję także zakup książki o Equinox która bez wątpienia będzie hitem biorąc pod uwagę coraz większą popularyzację OSGi także po stronie oprogramowania serwerowego...

To był wyjątkowo udany rok. Mam nadzieję że kolejny będzie jeszcze ciekawszy.

Formatowanie plików JavaScript w generatorze XPAND

Mechanizm szablonów XPAND jest moim ulubionym generatorem kodu. Jest nieprawdopodobnie wygodny i posiada wiele unikalnych cech które naprawdę ułatwiają pracę. Tematem tego wpisu (tutoriala) będą tzw. upiększacze kodu.

W generatorze XPAND domyślnie mamy dwa takie upiększacze: JavaBeautifier oraz XmlBeautifier. Jeżeli generujemy kod w jednej z obsługiwanych notacji dzięki dodaniu tych klas do procesu mamy pięknie sformatowany i czytelny kod wynikowy. Co jednak jeżeli generujemy kod JavaScript gdy budujemy aplikację webową? Cóż wynik nie jest najciekawszy. Praktycznie wygenerowanie czytelnego kodu graniczy z cudem i wymaga tworzenie naprawdę nieczytelnych szablonów które symulują częściowo formatowanie wynikowe co stanowi wyjątkowo brzydki anty-wzorzec. Koszmar którego nawet nie będę prezentował.

Dlaczego nie ma domyślnie klasy formatującej JavaScript w pakiecie XPAND? Odpowiedzią jest oczywiście nieskończona ilość generowanych notacji. Spróbujmy więc czy napisanie klasy pomocniczej dla JavaScript jest trudne.

Od czego zacząć? Myślę że powinniśmy postępować zgodnie z metodologią "Monkey see/Monkey do" zaprezentowaną kilka lat temu przez Ericha Gammę w książce "Contributing to Eclipse". Co kryje się pod tym tajemniczym sformułowaniem? Prosta zasada "zobacz jak robią to inni, skopiuj i dostosuj rozwiązanie do swoich potrzeb".

Zobaczmy więc jak działa klasa JavaBeautifier. Otwieramy sobie jej źródło i wszystko staje się jasne. Klasa ta implementuje interfejs PostProcessor z metodą: beforeWriteAndClose(FileHandle fileHandle) odpowiedzialną za formatowanie kodu. Sam proces formatowania przekazywany jest do mechanizmów JDT wykorzystując klasę: org.eclipse.jdt.core.formatter.CodeFormatter;

Cały process wygląda mniej więcej następująco:

beforeWriteAndClose(final FileHandle fileHandle){
  jeżeli rozszerzenie == 'java' to:
    Document doc = new Document(fileHandle.getBuffer().toString());
    TextEdit edit = getCodeFormatter().format(
      CodeFormatter.K_COMPILATION_UNIT, doc.get(), 0, doc.get().length(), 0, null);
    edit.apply(doc);
    fileHandle.setBuffer(new StringBuffer(doc.get()));
}


CodeFormatter getCodeFormatter() {
  inicjacja opcji na podstawie ustawień formatowania
  return ToolFactory.createCodeFormatter(options);
}


Jak widać całość opiera się o gotowe mechanizmy formatujące. Ponieważ identyczne możliwości formatowania kodu zostały zaimplementowane także w WTP dla edytora JavaScript wykorzystanie tego podejścia nie wydaje się być problemem. Jak jednak znaleźć odpowiedni kod w środowisku złożonym z grubo ponad tysiąca projektów jeżeli nie wiemy gdzie mechanizmy te zostały zaimplementowane? Wykorzystamy mechanizm Plugin Spy pokazujący nam informacje o praktycznie dowolnym elemencie środowiska. Otwieramy edytor JavaScript dostarczany z pakietem WTP, ALT+SHIFT+F1 i pojawia nam się następująca informacja:



Skoro wiemy już że edytor ten został dostarczony przez plugin WST.JSDT wgrywamy go do naszego workspace. W tym celu wykorzystujemy kreator:

Plug-in Development|Plug-ins and Fragments|Binary Project with linked content|filtr *wst.jstd i ściągamy podejrzane projekty:

org.eclipse.wst.jsdt.core
org.eclipse.wst.jsdt.core.ui


Praktycznie od razu zauważamy pakiet formatter a w nim klasę w której znajduje się identyczny kod:

org.eclipse.wst.jsdt.core.formatter.CodeFormatterApplication

Wywołanie mechanizmów formatujących JSDT wymagać będzie od nas zaledwie zmiany dwóch importów z JDT na JSDT oraz identyfikatora określającego formatowaną zawartość. Postępując z wzorcem małpki kopiujemy oryginalną zawartość klasy JavaBeautifer do nowej klasy o nazwie JavaScriptBeautifier. Następnie modyfikujemy importy:

//import org.eclipse.jdt.core.ToolFactory;
//import org.eclipse.jdt.core.formatter.CodeFormatter;
import org.eclipse.wst.jsdt.core.ToolFactory;
import org.eclipse.wst.jsdt.core.formatter.CodeFormatter;


sprawdzane rozszerzenie pliku oraz identyfikator:

//getCodeFormatter().format(CodeFormatter.K_COMPILATION_UNIT,..
getCodeFormatter().format(CodeFormatter.K_JAVASCRIPT_UNIT,...


Klasa upiększająca kod JavaScript jest gotowa. Ostatnim elementem jest ustalenie konfiguracji w jaki sposób kod powinien się formatować. W tym celu korzystając z kreatora tworzymy właściwy dla naszych projektów sposób formatowania (najlepiej zwiększyć długość linii z 80 do 140...160 co jest moim zdaniem optymalne dla kodu generowanego)



Ustawienia te zostaną zapisane w pliku:
[workspace].metadata\.plugins\org.eclipse.core.runtime\.settings\ org.eclipse.wst.jsdt.core.prefs

Kopiujemy plik konfiguracyjny do naszego projektu w którym wykorzystujemy nasz formater i gotowe. Całość zabrała nam zaledwie kilka minut (napisanie tego tutoriala trochę więcej).

Mam nadzieję że komuś taka klasa się przyda. W czasach absolutnej dominacji aplikacji webowych, technologii Ajax, przeglądarki Google Chrome etc. coraz częściej generujemy kod JavaScript a nic tak nie cieszy jak kod czytelny i dobrze sformatowany :)

Wykłady, wykłady, wykłady…

Korzystając z zaproszenia dr inż. Lecha Madeyskiego miałem dziś okazję przeprowadzić wykład dla studentów politechniki Wrocławskiej. Tematem było tworzenie narzędzi na bazie platformy Eclipse. Ponieważ chciałem zaprezentować słuchaczom tematykę jak najszerzej zdecydowałem się na prawdziwy maraton. Postanowiłem przedstawić przekrój przez zagadnienie od konfiguracji środowiska i struktury prostego pluginu po zbudowanie zestawu współpracujących edytorów (strukturalny, graficzny i tekstowy).

Jako problem postawiony przed tworzonymi narzędziami wykorzystałem koncepcje przedstawione na ostatnim spotkaniu Wrocławskiej Grupy Użytkowników Java, tzn. ServiceMix/Apache Camel. Środowisko Apache Camel wykorzystywane jest do zarządzania przepływem wiadomości. Przepływ taki składa się z wielu wzajemnie połączonych elementów realizujących poszczególne etapy zadania. Jednym z kluczowych elementów jest router operujący na zawartości. Wynikowy plik konfiguracyjny silnika wymaga informacji o przepływie oraz podejmowanych decyzjach (z odwołaniem do struktury wiadomości). Tym samym jest to idealny przykład by zaprezentować koncepcje budowy zestawu narzędzi.



Podczas prezentacji zbudowaliśmy uproszczony model logiczny takich przepływów. Na jego bazie utworzyliśmy edytor graficzny umożliwiający łączenie na diagramie abstrakcyjnych elementów. Ponieważ notacja graficzna nie nadaje się do definiowania reguł podejmowania decyzji utworzyliśmy dodatkowo specjalizowany edytor tekstowy. Edytor ten umożliwił nam zdefiniowanie zestawu reguł wraz z warunkami. By warunki mogły operować na realnych polach zdefiniowanych w opisie struktury wiadomości (zamiast prostych łańcuchów tekstowych) zintegrowaliśmy całość z edytorem diagramów klas UML. Tym samym udało się poruszyć wszystkie ważne aspekty budowy narzędzi:
  • dostosowanie narzędzi do problemu
  • notacje strukturalne, graficzne, tekstowe
  • walidacje poprawności, podpowiedzi etc.
  • integrację z istniejącymi narzędziami




Całość wykładu zaplanowałem na 1h demo plus 30min teorii. Niestety wykonanie demonstracji krok po kroku okazało się w tak krótkim czasie bardzo trudne więc część elementów wytłumaczyłem na bazie przygotowanych wcześniej plików. Myślę że takie podejście jest bardziej realistyczne ponieważ czas tracony na pisanie kodu od podstaw można lepiej poświęcić na dokładniejsze wytłumaczenie co, jak i dlaczego. Myślę że doświadczenie to wykorzystam podczas kolejnej prezentacji która odbędzie się już za tydzień w ramach spotkań Wrocław JUG. Mam nadzieję że uda się całość skrócić do 1h.

Oczywiście zapraszam wszystkich zainteresowanych w imieniu swoim oraz całego Wrocław JUG:

Czwarte spotkanie Wrocławskiej Grupy Użytkowników Technologii Java:
"Tworzenie własnych narzędzi na platformie Eclipse"


26 maja 2009 o godzinie 18:30.
Instytut Informatyki Uniwersytetu Wrocławskiego,
Sala wykładowa Kameralna Wschodnia nr 119, I piętro.

Wrocławska Grupa Użytkowników Java

Skoro już znalazłem czas na aktualizację bloga nie mogę nie wspomnieć o pewnym ważnym wydarzeniu, które miało niedawno miejsce we Wrocławiu. Pod koniec lutego powstała Wrocławska Grupa Użytkowników Java, czyli w skrócie Wrocław JUG. Poniżej kilka ważnych linków:

Grupa dyskusyjna Wrocław JUG
Profil JUG'a na LinkedIn

Eclipse w bankowości - podsumowanie

Trzy tygodnie temu odbyło się w Londynie spotkanie Eclipse Banking Day. Miało ono na celu zebranie ludzi z firm deweloperskich, banków oraz innych instytucji finasowych tak by rozpocząć otwartą dyskusję na temat przyszłości rozwiązań budowanych na platformie Eclipse. Myślę że inicjatywa zakończyła się sukcesem.

A jak to wyglądało? Spotkanie rozpoczęło się od prezentacji koncepcji E4 czyli stworzenia Eclipse IDE jako aplikacji WWW. Raczej jestem sceptycznie nastawiony do idei tworzenia aplikacji WWW z tak złożonym interfejsem użytkownika. Bardzo podoba mi się za to idea włączenia biblioteki EMF jako składnika bazowego na poziom platformy oraz utworzenie modeli dla każdego aspektu budowy aplikacji. Application.ecore, Workbench.ecore... to będzie coś naprawdę wielkiego :)

Następnie Neil Bartlett przedstawił wykład na temat warstwy usług deklaratywnych z OSGi. Podczas wykładu Neil wyjaśnił szczegółowo zagadnienia podziału OSGi na warstwy oraz opowiedział o wadach, zaletach poszczególnych implementacji Equinox DS, Spring DM, iPojo etc.
Technologia OSGi w ostatnich latach coraz bardziej się popularyzuje. I powinna! Choć od ponad pięciu lat tworzę rozwiązania bazowane na środowisku Eclipse przyznam że tylko w ostatnim projekcie (ostatnie trzy lata) staram się świadomie wykorzystywać możliwości modularyzacji. Wiem teraz że nic tak dobrze nie sprząta architektury aplikacji jak dobrze zaplanowana modularyzacja. Trzymam kciuki za sukces tematu także w świecie aplikacji JEE. Jeżeli ktoś jednak nie zetknął się jeszcze z tą tematyką koniecznie powinien przeczytać tutorial przygotowany właśnie przez Neila lub aktualny szkic jego książki.

Kolejny wykład poprowadził Sven Efftinge, lider projektu Eclipse TMF (Textual Modeling Framework, xText) o którym wspominałem w poprzednim wpisie. To było to na co tak naprawdę czekałem. Możliwość zadania setki pytań na temat projektu, oraz innych zagadnień z dziedziny MDE to właśnie główny powód, dla którego warto uczestniczyć w tego typu spotkaniach nawet jeżeli odbywają się one na drugim końcu europy.

Pozostałe wykłady dotyczyły specyficznych produktów dla sektora bankowego. Co dużo mówić królowały tutaj dwa tematy: raportowanie czyli BIRT oraz modelowanie procesów bankowych na wszystkie możliwe sposoby. Przedstawiona została także koncepcja wspólnej platformy dla sektora bankowego, która to właśnie dyskutowana była do późnego wieczora. To bez wątpienia projekt, którym muszę się zainteresować. Spotkanie skończyło się późnym wieczorem przy winie :) To była doskonała okazja by poznać kilka ciekawych osób.

A sam Londyn? Przepiękne miasto. Zrobiłem setkę zdjęć choć miałem na zwiedzanie zaledwie kilka godzin. Wybrałem kilka zdjęć i wrzuciłem na www.

Eclipse w bankowości

Już za tydzień odbędzie się w Londynie kolejne spotkanie poświęcone wykorzystaniu środowiska Eclipse jako bazy dla nowoczesnego oprogramowania dla bankowości. Oj będzie się działo. Projektanci i architekci z blisko 40 banków/instytucji finansowych oraz firm tworzących rozwiązania dla tego sektora, w sumie ponad 80 osób. Tematem przewodnim klasycznie będzie BIRT, DSL oraz OSGI. Pełna agenda spotkania znajduje się pod tym adresem:

http://wiki.eclipse.org/EclipseBankingDayLondon

Jeszcze nie zdecydowałem się do końca które prezentacje wybrać, to naprawdę trudna sprawa by z czegoś zrezygnować. Myślę jednak, że wybiorę tematy mi najbliższe czyli wszystkie mutacje modelowania czegokolwiek ze szczyptą BIRT’a jako przyprawą całości. Półtorej roku temu podczas ESE w Ludwigsburgu odkryłem oAW które naprawdę ułatwiło mi życie, mam nadzieję że i tym razem uda mi się wrócić z jakąś nową zdobyczą. Na pewno będą nią ciekawe znajomości :)

Tekstowe języki specjalizowane

Przez kilka ostatnich miesięcy nie miałem czasu by zaktualizować bloga. Ciągły brak czasu związany z pracą oraz planowaniem pewnej dalekiej wyprawy etc. (która niestety została odwołana). W tym czasie w świecie modelowania wydarzyło się naprawdę sporo. Gdyby to wszystko chcieć tutaj opisać to pewnie mój blog zmieniłby się w wielki spis treści z listą odnośników. Kilka jednak elementów zasługuje na wyróżnienie/przypomnienie.

Bez wątpienia jednym z nich jest prezentacja 'Przyszłość języków programowania' z konferencji JAOO która odbyła się kilka miesięcy temu. Andres Hejlsberg, architekt z Microsoftu prezentuje jak języki zmieniały się w ostatnich latach oraz jakie stoją przed nimi kolejne wyzwania. Polecam prezentację ogląda się jak dobry film. Oczywiście szczególną uwagę warto zwrócić na zalety/cechy języków deklaratywnych/specjalizowanych :)



Skoro już jestem w klimatach MS nie mogę pominąć platformy Oslo zaprezentowanej na PDC2008. Poniższe linki prowadzą do poszczególnych fragmentów prezentacji. Na mnie największe wrażenie zrobiła interaktywność narzędzia do tworzenia gramatyk, taki xText na sterydach. Trzeba jednak pamiętać że to tylko prezentacja wersji alfa i sporo czasu upłynie zanim rozwiązanie ujrzy światło dzienne. Pewnie także niektóre elementy ulegną zmianie inne pewnie zostaną dodane (brak mechanizmu generacji kodu).



Technologie te nie są oczywiście czymś zupełnie nowym. To raczej odpowiedź na dynamicznie rozwijający się rynek rozwiązań DSL bazowanych na platformie Eclipse Modeling. Większość elementów to wprost odpowiedniki technologii ze świata Eclipse: EMF Ecore, xText etc. Nie zmniejsza to jednak wartości jaką wnosi tutaj Microsoft zarówno w warstwie technicznej (narzędzia interpretujące gramatykę w locie) jak i czysto marketingowej (szansa na większą popularyzację tematu).

Przykładowo bezpośrednim odpowiednikiem MGrammar jest xText. Technologia ta powstała jako składnik oAW jednak w grudniu ubiegłego roku dostała oficjalnie włączona do platformy Eclipse Modeling jako baza dla modułu TMF (razem z TCS). Poniżej link do prezentacji xText z ubiegłorocznej konferencji QCon2008



No i na zakończenie w formie podsumowania wspólna dyskusja twórców obu rozwiązań. Czyli kolejny odcinek podcastu dla programistów SE-Radio

Episode 123: Microsoft OSLO with Don Box and Doug Purdy

Rok 2009 zapowiada się naprawdę interesująco!