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

Google Chrome jako plugin w Internet Explorer?

Przeglądając powiadomienia RSS trafiłem na bardzo ciekawą informację. Google udostępniło dziś dodatek do przeglądarki Internet Explorer który umożliwia selektywne przełączanie jej w tryb zgodności z 'Google Chrome'. Dzięki temu uzyskujemy w Internet Explorerze nie tylko pełną zgodność ze standardami (100% w ACID3) ale także wysoką wydajność silnika JavaScript: Google Chrome V8.



Jak to działa? Idea jest prosta. Użytkownik instaluje odpowiedni plugin w przeglądarce a ty na swojej stronie umieszczasz deklarację że oczekujesz przeglądarki zgodnej z Google Chrome:

<meta http-equiv="X-UA-Compatible" content="chrome=1">

Jeżeli użytkownik ma zainstalowany dodatek Google Chrome Frame jest on wykorzystywany zamiast silnika Trident. Oczywiście w przypadku użytkowników z Internet Explorerem bez odpowiedniego rozszerzenia można wyświetlić prośbę o instalację dodatku. Odpowiedni skrypt został udostępniony przez Google pod tym adresem:

http://code.google.com/intl/pl-PL/chrome/chromeframe/developers_guide.html

Jeżeli nie możesz zmodyfikować strony alternatywną metodą jest prosta modyfikacja linku poprzez dodanie prefixu "cf:". Przykładowo aby zobaczyć 100% w ACID3 w przeglądarce IE8 wystarczy wpisać adres:

cf:http://acid3.acidtests.org/



Myślę że dzięki tej selektywności możliwe staje się tworzenie złożonych serwisów zgodnych ze standardami i dostarczanie ich klientom którzy są uzależnieni od oprogramowania zaprojektowanego dla Internet Explorera 6. Użytkownicy w dalszym ciągu będą korzystali IE6 z domyślnym silnikiem Trident, jedynie nasza aplikacja interpretowana będzie za pomocą silnika Google Chrome. Myślę że to idealne rozwiązanie gdy rezygnacja z Internet Explorera nie jest możliwa.

Czy odpowiedni znacznik pojawi się niedługo w popularnych serwisach Google? Odpowiedzią może być ten obrazek który został udostępniony na blogu przez zespół projektu Google Wave:

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 :)

Eclipse 3.5 Galileo

Wczoraj pojawiła się kolejna wersja środowiska Eclipse - Eclipse 3.5 Galileo. Co nowego? Jest tego naprawdę dużo. Włączenie do platformy modelowania środowiska OpenArchitectureWare, dalszy rozwój OSGi wraz z PDE, kolejna wersja środowiska BIRT, QVT, ATL, Compare... Jest tego za dużo by to wszystko wymienić.

Bez wątpienia każdy znajdzie coś dla siebie, w końcu to już 33 projekty zsynchronizowane i dostarczone jednocześnie :)

Nieudany wykład :(

Co tu dużo pisać, mój wczorajszy wykład to była tragedia. Całkowity chaos w którym sam się w pogubiłem i nie wiedziałem jak z tego wybrnąć. Szkoda bo miałem nadzieję że kogoś tematyką zainteresuję. Fragmenty wybrałem tak by stanowiły dopełniający się przykład, przygotowałem prościutkie demo plus jakieś slajdy. Tydzień wcześniej prowadziłem też identyczną prezentację na politechnice zakończoną powodzeniem. Nie mogło się nie udać... a jednak zakończyło się totalnym chaosem.

Co było powodem? Elementów prawdopodobnie było wiele. Myślę jednak że kluczowym był mój pomysł by prezentację skrócić o połowę. Robiąc ją wcześniej na politechnice przedstawiłem teorię dotyczącą Eclipse, DSL’i, pokazałem jak zbudowany jest plugin, oraz jak skonfigurować środowisko i przeglądać istniejący kod. Na takiej bazie mogłem dokładnie pokazać sposób budowy modelu EMF który jest kluczowym elementem procesu tworzenia narzędzi. Pozostały czas poświęciłem by pobieżnie zaprezentować jak tworzone są edytory tekstowe i graficzne na bazie modeli. Miało to ręce i nogi i mam nadzieję że ktoś się tematem zainteresował. No ale trwało prawie 2h...

Myślałem że za drugim razem będzie prościej. Skróciłem sobie czas do połowy wychodząc z założenia że nie będę ręcznie krok po kroku tworzyć modelu ale skorzystam z przygotowanego wcześniej pliku. Jednak nie przemyślałem planu skróconej prezentacji. Już w trakcie wiedziałem że nie mam czasu by dokładnie przedstawić teorię, później zbyt pobieżnie przedstawiłem rolę odwzorowania modelu do której pozostałe fragmenty się odwoływały. Całość wyglądała tak jakbym zaczął budować dom od pierwszego piętra i starał się go dokończyć zanim runie z powodu braku fundamentów i parteru.

Cóż myślę że nie udało mi się wczoraj zainteresować zbyt wielu osób tematyką Eclipse. Mam jednak nadzieję że przynajmniej udało mi się pokazać że tworzenie edytorów jest czynnością prostą. Szkoda tylko że nie zaprezentowałem wystarczająco dobrze jak się to robi i dlaczego.

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.

Eclipse SDK 3.5.1.I20090722_Shanghai

Już za kilka tygodni pojawi się nowa wersja środowiska Eclipse 3.5 Galileo. W tym roku jednak większą uwagę przyciąga jeden z buildów integracyjnych. Chodzi oczywiście o build 'Shanghai' planowany na 22 lipca 2009. Już dziś potwierdzono że jeżeli nie pojawią się błędy krytyczne oraz przejdą wszystkie testy jednostkowe to odbędzie się z tej okazji wyjątkowa uroczystość. Planowana jest niezliczona ilość atrakcji takich jak sztuczne ognie, orientalny alkohol, zaćmienie słońca oraz całonocny grill. Swoją obecność potwierdziła już lokalna telewizja która zapowiedziała bezpośrednią relację z procesu budowania aplikacji. Od strony technicznej pieczę nad uroczystością sprawuje firma NASA.

Szczegóły imprezy możecie znaleźć pod tym adresem: NASA/TP—2008–214169 (6.5 MB)

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