Programowanie asynchroniczne nie jest przyjemne. Każdy to wie. Nie dlatego że jest trudne bo można się wszystkiego nauczyć ale dlatego że kod jest nieczytelny jeżeli scenariusz wykracza poza 'Hello world'. Sam spędziłem lata pisząc rozwiązania bazowane na platformie Eclipse i moim najlepszym przyjacielem było 'asyncExec'. Jednak nawet pomimo tak przydatnych funkcji całość jest zwyczajnie nieczytelna. Pojawiło się jednak światło w tunelu - automatyczne przekształcanie kodu synchronicznego w asynchroniczny poprzez adnotacje dla kompilatora. Niestety nie jest to mechanizm dostępny w Javie ale i tak warto prezentację zobaczyć. To przyszłość każdego języka :)
Klasyczny program pisany jest imperatywnie. Komenda za komendą. Całość wywołuje się synchronicznie za pomocą jednego wątku. Jeżeli chcemy część pracy przekazać do innego wątku to musimy to jawnie napisać (stworzyć klasę anonimową np. Runnable, wywołać 'asyncExec' itp). Taki kod jednak szybko przestaje być czytelny. Trudno sobie wyobrazić czytelny kod z kilkoma zagnieżdżeniami. Nie wspominając już o obsłudze wyjątków czy wywołań zwrotnych itp. Szybko robi się z tego spagetti. Logika biznesowa w takim kodzie schodzi na plan dalszy a główne skrzypce gra tutaj aspekt techniczny kodu.
Czy to jedyna metoda? Wygląda na to że nie. Półtorej roku temu oglądałem materiały z PDC 2010 podczas których zapowiedziano iż MS pracuje nad wprowadzeniem obsługi asynchroniczności do jęzka C#. Temat wydał mi się diabelnie ciekawy ale zapomniałem o nim napisać. Wczoraj oglądając materiały z konferencji BUILD trafiłem na prezentację wersji finalnej która stała się podstawą nowego API Windows 8 (RuntimeRT).
O co chodzi? O to by programista mógł pisać zwyczajny kod wyglądający na synchroniczny ale kompilator potrafił przekształcić go w kod asynchroniczny bazowany na wywołaniach callback. Wygląda to niewiarygodnie. Można napisać metodę mającą 100 linii z czego np. 10 wywołań będzie wywołaniami asynchronicznymi. Kompilator rozbije taką metodą na serię metod zwrotnych. Nawet więcej można oznaczyć jakąś iterację że ma się wywołać równolegle a kolejna linijka kodu wykona się dopiero gdy przetworzone zostaną wszystkie elementy kolekcji. Całość sterowana dwoma prostymi słowami kluczowymi 'async' oraz 'await' umieszczanymi przy wywołaniu. To jest przyszłość jaką chciałbym kiedyś zobaczyć także w Javie.
Prezentację można zobaczyć na poniższym wideo. Poza wywołaniami asynchronicznymi architekt prezentuje jeszcze kilka innych ciekawych rozwiązań (np. pisanie programów które wywołują kompilator dodając nowe metody "w locie" które następnie ten kod wywołuje itp.). Całość jest imponująca
Mam nadzieję że Oracle znajdzie szybko porozumienie z Google i OpenJDK stanie się wspólną maszyną Javy wspieraną przez wszystkich producentów. Tak by język po kilku latach stagnacji znów rozwijał się tak szybko jak jeszcze 5 lat temu. Współpraca nad jedną wspólną maszyną wirtualną to konieczność by składnia języka dogoniła najnowsze trendy. Transformacja asynchroniczna w C# pokazuje że jeszcze sporo można zrobić na poziomie języka.
Prezentacja OSGi w JEE we Wrocławiu [Wrocław JUG]
Właśnie przeczytałem że jutro na Politechnice Wrocławskiej odbędzie się prezentacja "OSGI + J2EE". Została ona zorganizowana przez zespół R&D Eurobanku. Myślę że warto się na taką prezentację wybrać. W rozwinięciu przekleiłem informację ze strony JUG’a
--------------
Program prezentacji:
- Case study: System informatyczny z dużą liczbą rozwijanych jednocześnie obszarów
- Analiza potrzeby modularyzacji systemów informatycznych
- Przegląd i porównanie dostępnych technik modularyzacji w środowisku Java EE
- Wprowadzenie w kluczowe koncepcje OSGi
- Propozycja modelowej architektury łączącej zalety Java EE i OSGi
- Prezentacja praktycznego działania i architektury wielomodułowej platformy webowej
Politechnika Wrocławska (budynek B4)
Łukasiewicza 5
Sala 448
Zapisać można się poprzez stronę Wrocław JUG
--------------
Przy okazji jeżeli ktoś interesuje się tematem zachęcam do lektury książki "OSGi and Equinox". Czytałem ją rok temu i sporo mi wyjaśniła. Przy okazji jeżeli ktoś ma problemy z widocznoscią pakietów w trakcie integracji modułów to tutaj można znaleźć "niekonwencjonalne rozwiązanie":
http://deepdiveinto.blogspot.com/2010/06/jak-wamac-sie-do-obcego-bundla-w-osgi.html
--------------
Program prezentacji:
- Case study: System informatyczny z dużą liczbą rozwijanych jednocześnie obszarów
- Analiza potrzeby modularyzacji systemów informatycznych
- Przegląd i porównanie dostępnych technik modularyzacji w środowisku Java EE
- Wprowadzenie w kluczowe koncepcje OSGi
- Propozycja modelowej architektury łączącej zalety Java EE i OSGi
- Prezentacja praktycznego działania i architektury wielomodułowej platformy webowej
Politechnika Wrocławska (budynek B4)
Łukasiewicza 5
Sala 448
Zapisać można się poprzez stronę Wrocław JUG
--------------
Przy okazji jeżeli ktoś interesuje się tematem zachęcam do lektury książki "OSGi and Equinox". Czytałem ją rok temu i sporo mi wyjaśniła. Przy okazji jeżeli ktoś ma problemy z widocznoscią pakietów w trakcie integracji modułów to tutaj można znaleźć "niekonwencjonalne rozwiązanie":
http://deepdiveinto.blogspot.com/2010/06/jak-wamac-sie-do-obcego-bundla-w-osgi.html
Eclipse Demo Camp 2010 - Poznań
Niestety w tym roku nie udało mi się zorganizować trzeciej wrocławskiej edycji Eclipse Demo Camp. Do tej pory spotkania organizowałem dzięki pomocy firmy Sygnity. Firma jednak jakiś czas temu zakończyła rozwój projektów eclipsowych. Nie udało mi się znaleźć nowego sponsora więc tym razem trzeba było ze spotkania zrezygnować. Każdemu jednak kto czekał na wrocławską edycję polecam jutrzejsze spotkanie w Poznaniu!
Poznańska edycja Eclipse Demo Camp jest najstarsza w Polsce. Spotkania odbywają się dwa razy w roku od co najmniej 4 lat. Tym razem spotkanie odbędzie się w pubie Johnny Rocker. Spotkanie organizują w trójkę Natalia Klimasz i Krzysztof Daniel z IBM Eclipse Support Center oraz Adam Dudczak z Poznańskiej grupy JUG (Java User Group).
Plan spotkania wygląda następująco:
13.15 - Krzysztof Kaźmierczyk, IBM ESC, How to easy find Java memory problems using Eclipse using Memory Analyzing Tool
13.45 - Jacek Pospychala, Zend, Testowanie GUI w aplikacjach Eclipse RCP
14.15 - Krzysztof Daniel, IBM ESC, Server-Side Eclipse what it can do for you?
15.00 - Anna Ferster, Marek Kuzora & Filip Wiśniewski,Students PUT, Moduł rozszerzonych preferencji do Eclipse RCP
15.30 - Małgorzata Janczarska, IBM, Building web application on top of Eclipse
16.00 - Tomasz Zarna, IBM, Eclipse 3.7 Tips and tricks
Każdego zainteresowanego rozwojem środowiska Eclipse zapraszam w imieniu organizatorów. To będzie rewelacyjne spotkanie!
Wszystkie ważne informacje można znaleźć na oficjalnej stronie WIKI:
http://wiki.eclipse.org/Eclipse_DemoCamps_November_2010/Poznan
Jeżeli ktoś ma konto w serwisie Facebook można także dodać się do specjalnie utworzonego wydarzenia (dzięki temu wasi znajomi dowiedzą się o spotkaniu EDC Poznań). Nie jest to jednak równoznaczne z rejestracją. To tylko taki opcjonalny dodatek w ramach grupy 'eclipse.polska'
http://www.facebook.com/event.php?eid=155588817818747
Miałem okazję być na kilku wcześniejszych poznańskich spotkaniach i zawsze było rewelacyjnie (raz była nawet mata do Dance Dance Revolution!). Zawsze starałem się tak zaplanować swoje delegacje do poznańskiego oddziału PB Polsoft by po pracy móc być także na EDC (spotkania były wieczorami w ciągu tygodnia więc można było na nie jechać tylko z pracy). Żałuję że niestety nie będę mógł tym razem przyjechać (anulowałem więc prezentację XText). Mam nadzieję że następnym razem uda mi się lepiej zaplanować swój czas tak by nie kolidowały mi dwie ważne sprawy.
Mam także nadzieję że uda mi się zorganizować trzecie wrocławskie EDC w czerwcu. Wszystko jednak zależy od tego czy znajdzie się jakaś firma rozwijająca projekty w technologiach eclipsowych która chciałaby całość sponsorować. Biorąc pod uwagę że coraz więcej firm stara się wejść w technologię EclipseEquinox/OSGI to mam nadzieję że uda się coś znaleźć. W końcu takie spotkania to idealny sposób by znaleźć pracowników znających od lat OSGI w praktyce - to możliwe tylko w EclipseRCP :)
Poznańska edycja Eclipse Demo Camp jest najstarsza w Polsce. Spotkania odbywają się dwa razy w roku od co najmniej 4 lat. Tym razem spotkanie odbędzie się w pubie Johnny Rocker. Spotkanie organizują w trójkę Natalia Klimasz i Krzysztof Daniel z IBM Eclipse Support Center oraz Adam Dudczak z Poznańskiej grupy JUG (Java User Group).
Plan spotkania wygląda następująco:
13.15 - Krzysztof Kaźmierczyk, IBM ESC, How to easy find Java memory problems using Eclipse using Memory Analyzing Tool
13.45 - Jacek Pospychala, Zend, Testowanie GUI w aplikacjach Eclipse RCP
14.15 - Krzysztof Daniel, IBM ESC, Server-Side Eclipse what it can do for you?
15.00 - Anna Ferster, Marek Kuzora & Filip Wiśniewski,Students PUT, Moduł rozszerzonych preferencji do Eclipse RCP
15.30 - Małgorzata Janczarska, IBM, Building web application on top of Eclipse
16.00 - Tomasz Zarna, IBM, Eclipse 3.7 Tips and tricks
Każdego zainteresowanego rozwojem środowiska Eclipse zapraszam w imieniu organizatorów. To będzie rewelacyjne spotkanie!
Wszystkie ważne informacje można znaleźć na oficjalnej stronie WIKI:
http://wiki.eclipse.org/Eclipse_DemoCamps_November_2010/Poznan
Jeżeli ktoś ma konto w serwisie Facebook można także dodać się do specjalnie utworzonego wydarzenia (dzięki temu wasi znajomi dowiedzą się o spotkaniu EDC Poznań). Nie jest to jednak równoznaczne z rejestracją. To tylko taki opcjonalny dodatek w ramach grupy 'eclipse.polska'
http://www.facebook.com/event.php?eid=155588817818747
Miałem okazję być na kilku wcześniejszych poznańskich spotkaniach i zawsze było rewelacyjnie (raz była nawet mata do Dance Dance Revolution!). Zawsze starałem się tak zaplanować swoje delegacje do poznańskiego oddziału PB Polsoft by po pracy móc być także na EDC (spotkania były wieczorami w ciągu tygodnia więc można było na nie jechać tylko z pracy). Żałuję że niestety nie będę mógł tym razem przyjechać (anulowałem więc prezentację XText). Mam nadzieję że następnym razem uda mi się lepiej zaplanować swój czas tak by nie kolidowały mi dwie ważne sprawy.
Mam także nadzieję że uda mi się zorganizować trzecie wrocławskie EDC w czerwcu. Wszystko jednak zależy od tego czy znajdzie się jakaś firma rozwijająca projekty w technologiach eclipsowych która chciałaby całość sponsorować. Biorąc pod uwagę że coraz więcej firm stara się wejść w technologię EclipseEquinox/OSGI to mam nadzieję że uda się coś znaleźć. W końcu takie spotkania to idealny sposób by znaleźć pracowników znających od lat OSGI w praktyce - to możliwe tylko w EclipseRCP :)
Prezentacja Eclipse Virgo (SpringSource dmServer)
Dziś o godzinie 17.00 odbędzie się prezentacja projektu Eclipse Virgo (dawniej znanego jako SpringSource dmServer). Prezentację poprowadzą jego liderzy: Glyn Normington oraz Steve Powell. Prezentacja odbędzie się na platformie Eclipse Live więc każdy będzie mógł uzyskać odpowiedzi na własne pytania.
Rejestracja możliwa jest pod tym adresem:
http://live.eclipse.org/node/937
Więcej informacji o projekcie Eclipse Virgo możecie znaleźć na stronie projektu:
http://www.eclipse.org/virgo/
Jako programista środowiska Eclipse od wielu lat mam możliwość pracy w środowisku OSGi. Nic tak nie porządkuje kodu jak przemyślana modularyzacja z wymuszonymi jednokierunkowymi zależnościami pomiędzy modułami + usługi/rozszerzenia. Bez wątpienia jestem wielkim fanem tej technologi :) Dlatego bardzo cieszy mnie jej ekspansja także na platformę JEE/J2EE. Mam nadzieję że znajdę trochę czasu by wrzucić na bloga jakiś dłuższy wpis o usługach, modularyzacji i tematach pokrewnych. Jak w każdej technologii także w OSGi jest kilka kruczków które dobrze znać (np. upublicznić pakiet prywatny z zewnętrznej biblioteki)
Jeżeli ktoś z was jest zainteresowany powiadomieniami o kolejnych prezentacjach, wykładach, spotkaniach zapraszamy do oficjalnej grupy 'Eclipse Polska na Facebooku'
---------------------------------
Aktualizacja
Link do nagranej prezentacji:
Rejestracja możliwa jest pod tym adresem:
http://live.eclipse.org/node/937
Więcej informacji o projekcie Eclipse Virgo możecie znaleźć na stronie projektu:
http://www.eclipse.org/virgo/
Jako programista środowiska Eclipse od wielu lat mam możliwość pracy w środowisku OSGi. Nic tak nie porządkuje kodu jak przemyślana modularyzacja z wymuszonymi jednokierunkowymi zależnościami pomiędzy modułami + usługi/rozszerzenia. Bez wątpienia jestem wielkim fanem tej technologi :) Dlatego bardzo cieszy mnie jej ekspansja także na platformę JEE/J2EE. Mam nadzieję że znajdę trochę czasu by wrzucić na bloga jakiś dłuższy wpis o usługach, modularyzacji i tematach pokrewnych. Jak w każdej technologii także w OSGi jest kilka kruczków które dobrze znać (np. upublicznić pakiet prywatny z zewnętrznej biblioteki)
Jeżeli ktoś z was jest zainteresowany powiadomieniami o kolejnych prezentacjach, wykładach, spotkaniach zapraszamy do oficjalnej grupy 'Eclipse Polska na Facebooku'
---------------------------------
Aktualizacja
Link do nagranej prezentacji:
'Eclipse w Polsce' w serwisie Facebook
Właśnie wróciłem z Krakowa w którym odbyła się kolejna edycja spotkania Eclipse Demo Camp. Podczas spotkania pojawiło się kilka fajnych tematów miałem także okazję po raz kolejny nakłaniać słuchaczy do wypróbowania środowiska XText. Samo spotkanie opisze jednak w kolejnym wpisie jak sobie wszystko poukładam w głowie. Teraz czas na Facebooka :)
W ciągu ostatnich 4 lat wspólnie z wami zorganizowaliśmy sporo spotkań z cyklu EDC. Celem tych spotkań było nie tylko nakłonienie ludzi by wypróbowali technologie z rodziny Eclipse ale przede wszystkim chęć zbudowania polskiej społeczności związanej z tym tematem. Coś jak JUG’i które od wielu lat grupują pasjonatów języka Java. We Wrocławiu zorganizowaliśmy dwa takie spotkania i zauważyłem że nie do końca wszystko działa tak jak planowałem.
Ludzie zapisywali się na spotkania, przychodzili, dyskutowali (często do nocy jak podczas 'EDC 2009 Wrocław' które trwało prawie 7h!)... Sukces? Nie do końca. Po pierwsze nie udało mi się kontaktów z EDC utrzymać na dłużej, po drugie na kolejnym spotkaniu nie kojarzyłem osób które były na poprzednim. Po prostu za bardzo byłem zajęty organizacją całości, przygotowywaniem kawy i herbaty by móc kogokolwiek zapamiętać (nie zawsze miałem czas by nawet spokojnie posłuchać prezentacji)
Postanowiliśmy to zmienić. Po dyskusji podczas EDC z Szymonem i Tomkiem zdecydowaliśmy się utworzyć 'społecznościową stronę' w serwisie Facebook: http://www.facebook.com/eclipse.polska.
Chcemy by strona ta była miejscem w którym każdy będzie mógł się dowiedzieć co ciekawego dzieje się w polskiej społeczności Eclipse. Zapisać się na kolejne EDC oraz inne spotkania/wykłady na których będzie poruszana ta tematyka. Każdy kto dołączy do społeczności będzie mógł wrzucać na tablicę ważne informacje dotyczące platformy (zdjęcia, wideo, linki etc). Możliwa będzie także dyskusja na różne tematy za pomocą forum dysksyjnego Facebooka (choć fajnie byłoby także dodać jako zakładkę istniejące forum - wie może ktoś jak to zrobić?)
No i na koniec najważniejsze czyli tagowanie zdjęć. Chcemy zachęcić wszystkich którzy uczestniczyli w spotkaniach EDC w ciągu ostatnich kilku lat by oznaczyli się na archiwalnych zdjęciach. Pozwoli nam to dowiedzieć się kto uczestniczył w spotkaniach i jakoś wspólnie stworzyć solidne podstawy społeczności Eclipse w Polsce. Nie znaleźliśmy zdjęć ze wszystkich spotkań (część galerii jest pusta) ale postaramy się to uzupełnić. Jeżeli ktoś ma takie zdjęcia prosiłbym o kontakt na 'deepdiveinto' na gmail.
Wszystkich zainteresowanych rozwojem środowiska Eclipse serdecznie zapraszamy :)
W ciągu ostatnich 4 lat wspólnie z wami zorganizowaliśmy sporo spotkań z cyklu EDC. Celem tych spotkań było nie tylko nakłonienie ludzi by wypróbowali technologie z rodziny Eclipse ale przede wszystkim chęć zbudowania polskiej społeczności związanej z tym tematem. Coś jak JUG’i które od wielu lat grupują pasjonatów języka Java. We Wrocławiu zorganizowaliśmy dwa takie spotkania i zauważyłem że nie do końca wszystko działa tak jak planowałem.
Ludzie zapisywali się na spotkania, przychodzili, dyskutowali (często do nocy jak podczas 'EDC 2009 Wrocław' które trwało prawie 7h!)... Sukces? Nie do końca. Po pierwsze nie udało mi się kontaktów z EDC utrzymać na dłużej, po drugie na kolejnym spotkaniu nie kojarzyłem osób które były na poprzednim. Po prostu za bardzo byłem zajęty organizacją całości, przygotowywaniem kawy i herbaty by móc kogokolwiek zapamiętać (nie zawsze miałem czas by nawet spokojnie posłuchać prezentacji)
Postanowiliśmy to zmienić. Po dyskusji podczas EDC z Szymonem i Tomkiem zdecydowaliśmy się utworzyć 'społecznościową stronę' w serwisie Facebook: http://www.facebook.com/eclipse.polska.
Chcemy by strona ta była miejscem w którym każdy będzie mógł się dowiedzieć co ciekawego dzieje się w polskiej społeczności Eclipse. Zapisać się na kolejne EDC oraz inne spotkania/wykłady na których będzie poruszana ta tematyka. Każdy kto dołączy do społeczności będzie mógł wrzucać na tablicę ważne informacje dotyczące platformy (zdjęcia, wideo, linki etc). Możliwa będzie także dyskusja na różne tematy za pomocą forum dysksyjnego Facebooka (choć fajnie byłoby także dodać jako zakładkę istniejące forum - wie może ktoś jak to zrobić?)
No i na koniec najważniejsze czyli tagowanie zdjęć. Chcemy zachęcić wszystkich którzy uczestniczyli w spotkaniach EDC w ciągu ostatnich kilku lat by oznaczyli się na archiwalnych zdjęciach. Pozwoli nam to dowiedzieć się kto uczestniczył w spotkaniach i jakoś wspólnie stworzyć solidne podstawy społeczności Eclipse w Polsce. Nie znaleźliśmy zdjęć ze wszystkich spotkań (część galerii jest pusta) ale postaramy się to uzupełnić. Jeżeli ktoś ma takie zdjęcia prosiłbym o kontakt na 'deepdiveinto' na gmail.
Wszystkich zainteresowanych rozwojem środowiska Eclipse serdecznie zapraszamy :)
Eclipse Demo Camp 2010 - Kraków
Już jutro odbędzie się kolejne spotkanie z cyklu Eclipse Demo Camp. W imieniu organizatorów zapraszam każdego zainteresowanego technologiami związanymi ze środowiskiem Eclipse.
Prezentacje będą bardzo krótkie ponieważ główny nacisk położony będzie na dyskusje tematyczne. Każdy zainteresowany będzie miał więc możliwość uzyskania odpowiedzi na swoje pytania związane z technologiami Eclipse. Ja z mojej strony obiecuję odpowiadać na wszystkie pytania dotyczące technologii związanych z modelowaniem, językami specjalizowanymi (nie tylko na temat xText)
http://wiki.eclipse.org/Eclipse_DemoCamps_Helios_2010/Krakow
Prezentacje będą bardzo krótkie ponieważ główny nacisk położony będzie na dyskusje tematyczne. Każdy zainteresowany będzie miał więc możliwość uzyskania odpowiedzi na swoje pytania związane z technologiami Eclipse. Ja z mojej strony obiecuję odpowiadać na wszystkie pytania dotyczące technologii związanych z modelowaniem, językami specjalizowanymi (nie tylko na temat xText)
http://wiki.eclipse.org/Eclipse_DemoCamps_Helios_2010/Krakow
11.00 - 11.30 | New and Noteworthy in Eclipse Helios, Platform Workspace Team |
11.30 - 11.45 | Eclipse 4.0 and e4, Tomasz Żarna, Platform Workspace Team |
12.15 - 12.30 | OSGI in the cloud, Krzysztof Daniel, IBM Eclipse Support Center |
12.30 - 12.45 | Cloud computing |
13.30 - 13.45 | BIRT - Raporty w Eclipsie, Łukasz Pobereźnik, IBM |
13.45 - 14.00 | XText, Grzegorz Białek |
14.30 - 14.45 | Eclipse Communication Framework, Paweł Pogorzelski, Platform Workspace Team |
14.45 - 15.00 | GWT development using Eclipse, Szymon Brandys, Platform Workspace Team |
Jak "włamać się" do obcego bundla w OSGi
Przeglądając swojego bloga zauważyłem że od dłuższego czasu nie pojawiały się na nim tematy stricte techniczne. Spowodowane to było między innymi małą ilością czasu. Dobrze byłoby to zmienić by blog zachował swój pierwotny charakter. Ponieważ ostatnie kilka lat spędziłem pracując nad rozwojem technologii Eclipse postanowiłem zacząć od tej tematyki.
Temat dzisiejszy to integracja oprogramowania w modelu OSGi. Oczywiście nie będę tutaj opisywał mechanizmu ponieważ jest to bezcelowe. Istnieje setka tutoriali która wyjaśnia co i jak działa. Tutoriale te jednak zazwyczaj kończą się na prostych przykładach a z perspektywy pracy nad projektami modularnymi wiem że to zdecydowanie za mało. To co w 90% jest błogosławieństwem, to w 10% jest problemem. Jednym z takich tematów jest mechanizm ukrywania API.
Ukrywanie klas jest kluczowym aspektem opracowania dobrego API które będzie współpracowało przez lata z produktami rozwijanymi przez inne firmy. Dostawcy bibliotek określają które elementy kodu są publiczne a które prywatne. Co jednak gdy tworzymy zaawansowaną integrację systemów wykraczającą poza publiczne API? To ryzykowna sprawa jednak w realnych projektach czasami nieunikniona. W OSGi klasy z pakietów prywatnych są dla nas niedostępne... do czasu :)
Przykładowym scenariuszem może być próba integracji własnych narzędzi z edytorem JBoss Drools IDE którą robiłem kilka lat temu. Biblioteka ta praktycznie wszystkie pakiety miała prywatne. Między innymi pakiet w którym znajduje się klasa edytora którą byłem zainteresowany jako potencjalnym komponentem w multi-edytorze. Jak się do niej dostać? Istnieją dwie metody: "studencka" i poprawna.
Studencka polega na modyfikacji biblioteki i jak się każdy domyśla nie jest to najlepsze rozwiązanie (nawet jeżeli pozwala na to licencja). Zmodyfikowana biblioteka trafia na nasze serwery więc na nas spoczywa odpowiedzialność za jej dalsze uaktualnienia, zgłoszenia błędów etc. Znacznie podnosi to koszty utrzymania takiego rozwiązania. Dodatkowo coraz więcej bibliotek jest podpisanych certyfikatami by wykluczyć nieautoryzowane modyfikacje.
Jak więc poprawnie zaimplementować modyfikacje pliku Manifest.MF tak by nie modyfikować samego bundla? Odpowiedzią jest mechanizm 'fragments' platformy OSGi. Zazwyczaj służy on do dodawania plików z tłumaczeniami, bibliotek dla różnych systemów itp. Tym razem użyjemy go do naszego "włamania" i upublicznienia prywatnych pakietów.
By całość zademonstrować przygotowałem następujący przykład. Firma 'Private Library Company' dostarczyła nam bundla w którym między innymi znajduje się klasa potrafiąca zwrócić nam cały świat :) Niestety klasa znajduje się w pakiecie wewnętrznym który nie jest udostępniony w manifeście.
Nasza firma 'Client Plugin Company' przygotowuje aplikację dostaczającą usługę której zadaniem jest pozdrowienie całego świata. Musimy więc dostać się do klasy która potrafi zwrócić nam 'świat'. Posiadamy oczywiście zależność na bibliotekę jednak nie jest to wystarczające. Kod nie będzie działał ponieważ klasa 'World' nie jest widoczna.
By to zmienić musimy przygotować odpowiednie rozszerzenie dla posiadanej biblioteki. Wykorzystamy w tym przypadku mechanizm fragmentów bundli. Z założenia mechanizm ten nie może modyfikować elementów, dostarczać nowego API jednak do naszego "włamania" nadaje się jak najbardziej. Tworzymy projekt fragmentu rozszerzający bundle biblioteki, możemy go nazwać 'privatelibrary.customization'. Następnie tworzymy w nim ścieżkę identyczną z tą którą chcemy upublicznić i zakładamy w niej pustą klasę np. o nazwie 'PackagePublisher'. Po utworzeniu klasy pojawia nam się możliwość upublicznienia jej pakietu w manifeście fragmentu. Platforma OSGi by obsłużyć naszą publiczną klasę dodaje 'regułę publiczności' dla wybranego pakietu dla nadrzędnej biblioteki.
Tym samym w projekcie klienckim uzyskujemy dostęp do interesującej nas klasy prywatnej 'World'. By całość działała nasz dodatek musi być dostępny dla platformy. Jeżeli go usuniemy całość ponownie przestanie się kompilować a jeżeli element będzie niedostępny w ramach runtime pojawi się wyjątek ClassNotFound przy próbie odwołania się do klasy świata. Oczywiście nasza klasa 'PackagePublisher' którą upubliczniliśmy w tym pakiecie nie jest publicznie dostępna. Nie zezwala na to kontrakt mechanizmu fragmentów. Poniżej zrzut z poprawnie zdefiniowanego manifestu.
Mam nadzieję że całość nie jest zbyt zagmatwana. Starałem się zrobić na tyle długi wstęp by całość wyjaśnić łącznie ze scenariuszem kiedy takie obejścia stosujemy. Oczywiście nie nakłaniam nikogo do odwoływania się do klas prywatnych w zewnętrznych bibliotekach. Takie sytuacje nigdy nie powinny być rutyną. Jeżeli jednak jest to koniczne z punktu widzenia biznesu warto wiedzieć jak to zrobić poprawnie. Gotowy projekt dostępny jest pod adresem:
http://sites.google.com/site/deepdiveinto/Home/PrivatePackage.zip?attredirects=0&d=1
Obrazek z wróżką pochodzi z prezentacji: OSGi Best and Worst Practices
Jak zawsze zachęcam także każdego do wypróbowania dodatku Facebook Like Plus
Temat dzisiejszy to integracja oprogramowania w modelu OSGi. Oczywiście nie będę tutaj opisywał mechanizmu ponieważ jest to bezcelowe. Istnieje setka tutoriali która wyjaśnia co i jak działa. Tutoriale te jednak zazwyczaj kończą się na prostych przykładach a z perspektywy pracy nad projektami modularnymi wiem że to zdecydowanie za mało. To co w 90% jest błogosławieństwem, to w 10% jest problemem. Jednym z takich tematów jest mechanizm ukrywania API.
Ukrywanie klas jest kluczowym aspektem opracowania dobrego API które będzie współpracowało przez lata z produktami rozwijanymi przez inne firmy. Dostawcy bibliotek określają które elementy kodu są publiczne a które prywatne. Co jednak gdy tworzymy zaawansowaną integrację systemów wykraczającą poza publiczne API? To ryzykowna sprawa jednak w realnych projektach czasami nieunikniona. W OSGi klasy z pakietów prywatnych są dla nas niedostępne... do czasu :)
Przykładowym scenariuszem może być próba integracji własnych narzędzi z edytorem JBoss Drools IDE którą robiłem kilka lat temu. Biblioteka ta praktycznie wszystkie pakiety miała prywatne. Między innymi pakiet w którym znajduje się klasa edytora którą byłem zainteresowany jako potencjalnym komponentem w multi-edytorze. Jak się do niej dostać? Istnieją dwie metody: "studencka" i poprawna.
Studencka polega na modyfikacji biblioteki i jak się każdy domyśla nie jest to najlepsze rozwiązanie (nawet jeżeli pozwala na to licencja). Zmodyfikowana biblioteka trafia na nasze serwery więc na nas spoczywa odpowiedzialność za jej dalsze uaktualnienia, zgłoszenia błędów etc. Znacznie podnosi to koszty utrzymania takiego rozwiązania. Dodatkowo coraz więcej bibliotek jest podpisanych certyfikatami by wykluczyć nieautoryzowane modyfikacje.
Jak więc poprawnie zaimplementować modyfikacje pliku Manifest.MF tak by nie modyfikować samego bundla? Odpowiedzią jest mechanizm 'fragments' platformy OSGi. Zazwyczaj służy on do dodawania plików z tłumaczeniami, bibliotek dla różnych systemów itp. Tym razem użyjemy go do naszego "włamania" i upublicznienia prywatnych pakietów.
By całość zademonstrować przygotowałem następujący przykład. Firma 'Private Library Company' dostarczyła nam bundla w którym między innymi znajduje się klasa potrafiąca zwrócić nam cały świat :) Niestety klasa znajduje się w pakiecie wewnętrznym który nie jest udostępniony w manifeście.
Nasza firma 'Client Plugin Company' przygotowuje aplikację dostaczającą usługę której zadaniem jest pozdrowienie całego świata. Musimy więc dostać się do klasy która potrafi zwrócić nam 'świat'. Posiadamy oczywiście zależność na bibliotekę jednak nie jest to wystarczające. Kod nie będzie działał ponieważ klasa 'World' nie jest widoczna.
By to zmienić musimy przygotować odpowiednie rozszerzenie dla posiadanej biblioteki. Wykorzystamy w tym przypadku mechanizm fragmentów bundli. Z założenia mechanizm ten nie może modyfikować elementów, dostarczać nowego API jednak do naszego "włamania" nadaje się jak najbardziej. Tworzymy projekt fragmentu rozszerzający bundle biblioteki, możemy go nazwać 'privatelibrary.customization'. Następnie tworzymy w nim ścieżkę identyczną z tą którą chcemy upublicznić i zakładamy w niej pustą klasę np. o nazwie 'PackagePublisher'. Po utworzeniu klasy pojawia nam się możliwość upublicznienia jej pakietu w manifeście fragmentu. Platforma OSGi by obsłużyć naszą publiczną klasę dodaje 'regułę publiczności' dla wybranego pakietu dla nadrzędnej biblioteki.
Tym samym w projekcie klienckim uzyskujemy dostęp do interesującej nas klasy prywatnej 'World'. By całość działała nasz dodatek musi być dostępny dla platformy. Jeżeli go usuniemy całość ponownie przestanie się kompilować a jeżeli element będzie niedostępny w ramach runtime pojawi się wyjątek ClassNotFound przy próbie odwołania się do klasy świata. Oczywiście nasza klasa 'PackagePublisher' którą upubliczniliśmy w tym pakiecie nie jest publicznie dostępna. Nie zezwala na to kontrakt mechanizmu fragmentów. Poniżej zrzut z poprawnie zdefiniowanego manifestu.
Mam nadzieję że całość nie jest zbyt zagmatwana. Starałem się zrobić na tyle długi wstęp by całość wyjaśnić łącznie ze scenariuszem kiedy takie obejścia stosujemy. Oczywiście nie nakłaniam nikogo do odwoływania się do klas prywatnych w zewnętrznych bibliotekach. Takie sytuacje nigdy nie powinny być rutyną. Jeżeli jednak jest to koniczne z punktu widzenia biznesu warto wiedzieć jak to zrobić poprawnie. Gotowy projekt dostępny jest pod adresem:
http://sites.google.com/site/deepdiveinto/Home/PrivatePackage.zip?attredirects=0&d=1
Obrazek z wróżką pochodzi z prezentacji: OSGi Best and Worst Practices
Jak zawsze zachęcam także każdego do wypróbowania dodatku Facebook Like Plus
OSGI and Equinox
Właśnie dostałem długo oczekiwaną przesyłkę. Książka miała pojawić się jeszcze w ubiegłym roku ale w końcu jest :)
Autorem książki jest lider projektu Eclipse Equinox. To chyba najlepsza reklama dla każdego zajmującego się tematyką OSGi/Eclipse. Pełną recenzję możecie znaleźć w tutaj:
OSGi and Equinox: Creating Highly Modular Java Systems
Autorem książki jest lider projektu Eclipse Equinox. To chyba najlepsza reklama dla każdego zajmującego się tematyką OSGi/Eclipse. Pełną recenzję możecie znaleźć w tutaj:
OSGi and Equinox: Creating Highly Modular Java Systems
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!
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
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.)
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.
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 :)
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 :)
Subskrybuj:
Posty (Atom)