Stworzyłem wirtualną maszynę, zainstalowałem sobie próbnie najnowsze Ubuntu i po pokonaniu kilku drobnych trudności (instalacja tzw. Guest Additions i konfiguracja rozdzielczości) miałem Linuxa działającego na WinXP. To co bardzo mi się w VB podoba (patrze typowo konsumpcyjnie ) to “jednolite okienka” (ang. Seamless windows) o co chodzi najlepiej zoobrazuje poniższy filmik.

Coś podobnego widziałem kiedyś na Mac’u i zrobiło to na mnie spore wrażenie. Działa to nieźle, troche szwankuje współpraca z Trackpointem mojego laptopa, ale po podłączeniu zewnętrznej myszki wszystko śmiga.

Zacząłem się zastanawiać do czego mógłby się VB przydać, oczywiście testowanie. Wszechtestowanie , potrzebujesz IE 6? Nie ma sprawy. Potrzebujesz sprawdzić czy Java działa także na Fedorze? Proszę bardzo. Przyszło mi do głowy że można by stworzyć gotowe obrazy dysków z zainstalowanymi systemami operacyjnymi i wszystkimi fajnymi narzędziami developerskimi. Wystarczyłoby raz przygotować taki obraz i wszyscy mogliby z tego korzystać, wystarczy, że jedna osoba zaktualizuje wszystko do najnowszej wersji i reszta może korzystać.

Przeglądając prezentacje “Developing beyond localhost” Briana Leonarda z ostatniego Devoxxa znalazłem fenomenalny link. Na stronce VirtualBox images znajdziecie gotowe obrazy z zainstalowanymi i gotowymi do działania systemami operacyjnymi, mamy: Fedorę, Ubuntu, Damn Small Linux, Debiana (pełna lista). Nie jest to dokładnie to czego szukałem, ale też pewnie się przyda .

Możecie pobrać całość w zipie (gotowe do zaimportowania projekty NetBeansowe) lub gotowe do użycia pliki nbm (w update site wpiszcie : http://grejpfrut.org/examples/vvm-modules/updates.xml).

Tak jak poprzednio zaczniemy od implementacji fabryki tworzącej instancję naszej implementacji ApplicationType.

public class GrejpfrutApplicationTypeProvider extends MainClassApplicationTypeFactory {
@Override
  public ApplicationType createApplicationTypeFor(Application app, Jvm jvm, String mainClass) {
    if (app.isLocalApplication()) {
      return new GrejpfrutApplicationType(app.getPid(), mainClass);
    }
    return null;
  }
}

Warto pamiętać, że w zależności od dostępnych informacji zmienna mainClass nie zawsze musi zawierać nazwę głównej klasy.

W tym konkretnym przykładzie aplikacje grejpfrutowe to takie, które zostały uruchomione lokalnie.

Kolejny krok to nieco więcej pisania, ale dalej nic trudnego.

public class GrejpfrutApplicationType extends ApplicationType {

    protected final int appPID;
    protected final String name;

    public GrejpfrutApplicationType(int appPID, String name) {
        this.appPID = appPID;
        this.name = name;
    }
    @Override
    public String getName() {
        return "Grejpfrut "+name;
    }
    @Override
    public String getVersion() {
        return "blee.bleee";
    }
    @Override
    public String getDescription() {
        return "Application type for Grejpfrut";
    }
    @Override
    public Image getIcon() {
	//używamy tej saame ikonki co w poprzednim przykładzie (patrz poprzedni wpis)
        return Utilities.loadImage(FirstExamplePluginView.IMAGE_PATH, true);
    }
}

Teraz jeszcze zarejestrowanie nowego ApplicationType w klasie Installer (patrz poprzedni post).

public class Installer extends ModuleInstall {
    private static GrejpfrutApplicationTypeProvider INSTANCE = new GrejpfrutApplicationTypeProvider();

    @Override
    public void restored() {
        FirstExamplePluginViewProvider.initialize();
        ApplicationTypeFactory.getDefault().registerProvider(INSTANCE);
    }
    @Override
    public void uninstalled() {
        FirstExamplePluginViewProvider.unregister();
        ApplicationTypeFactory.getDefault().unregisterProvider(INSTANCE);
    }
}

Wprowadźmy jeszcze jedną małą zmianę w FirstExamplePluginViewProvider, dodając jedną nową metodę.

    @Override
    protected boolean supportsViewFor(Application app) {
        if (ApplicationTypeFactory.getApplicationTypeFor(app) instanceof GrejpfrutApplicationType) {
            return true;
        }
        return false;
    }

Stworzona w poprzednim odcinku zakładka będzie się wyświetlała tylko w przypadku gdy zostanie jej przypisany typ GrejpfrutApplicationType.

Czyścimy całość i odpalamy, co się teraz stanie? Jeżeli masz odpalone tylko NetBeans i VisualVM w którym została uruchomiona wtyczka to niczego nie zobaczysz. Dlaczego? Otóż na tyle na ile to rozumiem NetBeansApplicationType i VisualVMApplicationType zostały zarejestrowane przed GrejpfrutApplicationType. VVM przypisuje aplikacji pierwszy ApplicationType który uda mu się do niej dopasować więc nie dochodzi nawet do sprawdzania czy NetBeans i VVM są też grejpfrutami . Uruchom jakiegoś Eclipse’a ;P wtedy na drzewku Applications pojawi się nowy grejpfrut.

To by było na tyle jeżeli napotkacie jakieś ładne stactrace’y bawiąc się Shootoutem i moimi źródełkami dajcie znać.

Jeszcze jedna finalna uwaga – testowałem na platformie w wersji 6.01 więc już dość leciwej.

Potrzebny będzie również kod źródłowy gry Shootout autorstwa Dawida Weissa, orginalna wersja nie pozwalała na osadzenie gry w kontenerach Swingowych, musiałem więc wprowadzić kilka poprawek . Kod źródłowy dostępny jest tutaj. Aby zbudować jar’a wystarczy rozpakować archiwum i w katalogu shootout wydać polecenie: ant jar-netbeans w shootout/build znajdziecie finalnego jar’a.

Po zainstalowaniu Visual VM (można też użyć tego który znajduje się w Waszym JDK) i uruchomieniu NetBeans IDE możemy przystąpić do pracy. W niektórych miejscach korzystałem z wizardów NetBeansowych więc samo spojrzenie w kod tych próbek może nie dać wam pełnego obrazu jak najszybciej dojść do finalnego efektu

Visual VM to aplikacja stworzona w oparciu o NetBeans Paltform, przeglądając zawartość folderu aplikacji możecie natknąć się na charakterystyczne dla aplikacji NBP nazwy plików i katalogów. Zanim zaczniemy właściwą pracę musimy zarejestrować instację platformy NB, która znajduje się w Visual VM. Oprócz standardowych elementów NB są tam również moduły specyficzne dla Visual VM jak np. VisualVM-Application czy VisualVM-Core.

Aby zarejestrować instancje platformy należy wybrać z menu Tools>NetBeans Plaform i dodać nową platformę (przycisk Add Platform) – wskazujemy na katalog w którym został zainstalowany VisualVM

Rejestracja platformy umożliwi nam nie tylko zapewnienie pełnej zgodności z platformą na której uruchamiany będzie plugin, ale pozwoli również na debugowanie i szybkie uruchamianie tworzonego przez nas rozszerzenia w docelowym środowisku.

Tworzymy nowy projekt wybierając File>New Project>NetBeans Modules i z listy o prawej stronie wybrać Module Suite klikamy Next.

W następnym kroku kreatora wpisujemy nazwę projektu i wybieramy platformę w oparciu o którą będziemy rozwijali nasz zestaw modułów. W poprzednich krokach zarejestrowaliśmy instancję należącą do Visual VM i to właśnie ją wybieramy z listy rozwijanej.

Module Suite jest kontenerem dla modułów które są z jakichś względów są ze sobą powiązane, w wyniku naszych działań powstaną dwa moduły: właściwa wtyczka do VisualVM i drugi będący owijką na shootout.jar. Dlaczego tak? Scenariusz jest bardzo prosty wyobraźcie sobie, że została wydana nowa wersja Shooout i chcielibyśmy mieć ją w naszej wtyczce. Po dokonaniu niezbędnych zmian przez nas, użytkownicy wtyczki musieliby ściągać nie tylko nową wersję gry, ale i samą wtyczkę, którą już przecież mają. Aby więc w pełni wykorzystać zalety modułowości każda biblioteka wykorzystywana przez naszą wtyczkę powinna zostać opakowana w pewne dodatkowe informacje, które pozwolą instancji NetBeans Platform na aktualizację tylko tej konkretnej biblioteki.

Czas więc stworzyć Library Wrapper Module dla Shootout.jar. Klikamy File>New Project>NetBeans Module>Library Wrapper Module w pierwszym kroku kreatora trzeba podać ścieżkę do pliku jar, który opakowujemy i do pliku z licencją na której biblioteka jest/ma być udostępniania. W ostatnim kroku kreatora pojawia się pytanie o codebase, wpisujemy com.dawidweiss.shootout.

O czym jeszcze warto wspomnieć, pierwotnie Shootout.jar miał w manifeście ustawiony parameter Main-Class, który wskazywał na klasę posiadającą metodę main w której uruchamiana była gra. Powodowało to, że wtyczka po umieszczeniu w VisualVM nie działała. Wywalenie tego atrybutu z manifestu załatwiło sprawę. Niestety nie znam się na wnętrznościach NetBeans Platform więc nie jestem w stanie tego sobie wytłumaczyć bardziej racjonalnie.

Zależności w formie LWM mogą być deklarowane przez wszystkie moduły wchodzące w skład nadrzędnego Module Suite.

Mamy już jeden moduł, teraz czas przejść do najważniejszej części tego artykułu – tworzenia właściwej wtyczki do VisualVM.

Tworzymy nowy projekt File>New Project>NetBeans Module>Module, moduł powinien zostać dodany do stworzonego wcześniej Module Suite. W kolejnym kroku wpisujemy codebase : org.grejpfrut.vvm, w NetBeans 6.5 wpisanie poprawnego codebase uzupełnia również pozostałe pola formularza.

Kolejny krok to dodanie zależności, w oknie Projects klikamy prawym na węzeł reprezentujący moduł i wybieramy Properties. Następnie zakładka Libraries musimy mieć zadeklarowane następujące zależności: Module System API, shootout, Utilities API, VisualVM-Application i VisualVM-Core.

W oknie Projects klikamy prawym przyciskiem myszy na węzeł reprezentujący stworzony przed chwilą moduł i wybieramy New>Module Installer. Stworzona klasa Installer i jej dwie metody restored i uninstalled umożliwiają nam wpięcie się w cykl życia tworzonej właśnie wtyczki. Kod z metody restored jest wykonywany w chwili załadowania modułu, jest to najwłaściwsze miejsce aby zarejestrować klasy implementujące rozszerzenia. Natomiast metoda uninstalled jest wywoływana w momentcie gdy moduł jest usuwany ze środowiska lub gdy jest ono wyłączane.

public class Installer extends ModuleInstall {
    @Override
    public void restored() {
        FirstExamplePluginViewProvider.initialize();
    }
    @Override
    public void uninstalled() {
        FirstExamplePluginViewProvider.unregister();
    }
}

W mojej prezentacji z NetBeans Day możecie znaleźć krótkie omówienie tego co można rozszerzyć w VisualVM, więcej o tym piszę Geertjan w
dokumentacji VisualVM i na swoim blogu. FirstExamplePlugin będzie tworzył dodatkową zakładką, którą użytkownicy będą mogli zobaczyć po połączeniu się do jakiegoś JVMa. W zakładce tej będą się działy rzeczy różne .

Należy teraz stworzyć klasę FirstExamplePluginViewProvider, jak sugeruje nazwa, klasa ta będzie odpowiedzialna za “produkcję” instancji klasy FirstExamplePluginView.

class FirstExamplePluginViewProvider extends DataSourceViewProvider {
    //prosty singleton
    private static DataSourceViewProvider instance = new FirstExamplePluginViewProvider();

    static void initialize() {
        //rejestrujemy instancję FirstExamplePluginViewProvider w zarządcy widoków
        DataSourceViewsManager.sharedInstance().addViewProvider(instance, Application.class);
    }

    static void unregister() {
        //wyrejestrowujemy instancję FirstExamplePluginViewProvider w zarządcy widoków
	//metoda jest wywoływana podczas odinstalowywania modułu i wyłączania środowiska
        DataSourceViewsManager.sharedInstance().removeViewProvider(instance);
    }

    @Override
    protected DataSourceView createView(Application app) {
        //tworzy instancję widoku
        return new FirstExamplePluginView(app);
    }
}

Klasa ta to prosty singleton, który w czasie inicjalizacji modułu (initialize) dodaje do DataSourceViewManager’a swoją instancję. Najważniejszą metodą w tej klasie jest createView, która to tworzy naszą zakładkę.

Kopiując poniższy kod należy pamiętać o wskazaniu poprawnej ścieżki do ikonki wyświetlanej w etykiecie zakładki:
org/grejpfrut/vvmnbd/example/grejpfrut.png – szczegóły będą widoczne w źródłach.

public class FirstExamplePluginView extends DataSourceView {

    private DataViewComponent dvc;

    //sciezka do ikony, ktora bedzie wyswietlana w zakładce zakładki
    public final static String IMAGE_PATH = "org/grejpfrut/vvmnbd/example/grejpfrut.png";

    public FirstExamplePluginView(Application app) {
        //tytuł zakładki i ikona
        super(app, "Java IDE wars plugin", new ImageIcon(Utilities.loadImage(IMAGE_PATH)).getImage(), 3, true);
    }

    @Override
    protected DataViewComponent createComponent() {
    	//tworzenie elementów widoku
        JEditorPane generalDataArea = new JEditorPane();
        generalDataArea.setBorder(BorderFactory.createEmptyBorder(4, 8, 4, 8));

        JPanel details1Panel = new JPanel(new BorderLayout());
        ShootoutBoard board = new ShootoutBoard(new ShootoutUtilities().getEnemyFactory(), details1Panel);
        details1Panel.add(board, BorderLayout.CENTER);
        details1Panel.setBackground(Color.GRAY);
        details1Panel.setCursor(Cursor.getPredefinedCursor(Cursor.CROSSHAIR_CURSOR));

	//osadzanie stworzonych kontrolek w kontenerze VisualVM
        DataViewComponent.MasterView masterView = new DataViewComponent.MasterView("Java IDE wars plugin", null, generalDataArea);
	//konfiguracja widoku
        DataViewComponent.MasterViewConfiguration masterViewConfiguration = new DataViewComponent.MasterViewConfiguration(false);

	//tworzymy właściwy komponent, który bedzie wyswietlany w VVM
        dvc = new DataViewComponent(masterView, masterViewConfiguration);

	//tworzymy panel z planszą gry
        DataViewComponent.DetailsView details = new DataViewComponent.DetailsView("", "Detale tego okienka", 10, details1Panel, null);
	//umieszczamy go w odpowiednim miejscu
        dvc.addDetailsView(details, DataViewComponent.TOP_LEFT);
	//gra ma być domyślnie ukryta
        dvc.hideDetailsArea(DataViewComponent.TOP_LEFT);
        return dvc;
    }
}

Po uzupełnieniu importów, możemy uruchomić nasz plugin aby tego dokonać należy w oknie Projects kliknąć prawym na węzeł reprezentujący nasz Module Suite i wybrać “Run” lub “Debug”. NetBeans uruchomi teraz nasz plugin w platformie która wybraliśmy dla naszych modułów. Teraz klikamy w dowolny proces JVM, który jest wyświetlany na drzewku Applications i powinna się naszym oczom ukazać zakładka z grejpfrutem, po kliknięciu “Details” powinna już rozpocząć się strzelanina .

Kompletne źródła już wkrótce, po tym jak skończe drugą cześć “Własny ApplicationType”.

Wszystko oparte na serii artykułów Getting Started Extending VisualVM autorstwa Geertjana Wielengi.

Kilka słów podsumowania, z informacji które udało mi się zebrać wynika, że obie edycje odwiedziło w sumie około 140 osób (80 Gdańsk, około 60 w Poznaniu). Kurcze, wydaje się, że nie codzień jest okazja posłuchać tak świetnych specjalistów, ale wychodzi na to, że dobry poziom merytoryczny to nie wszystko…

Niestety nie byłem w stanie obejrzeć wszystkich poznańskich prezentacji, ominął mnie występ Geertjana Wielengi który omawiał podstawy NetBeans Platform. Nie mogę też za wiele powiedzieć o prezentacji Adam Kędziory bo ze względu na różne organizacyjne bzdury musiałem siedzieć przed salą. Bardzo podobała mi się prezentacja Toni’ego Epple, który pokazywał przykłady produkcyjnych wdrożeń NBPlatform. Jestem ciekaw czy ktoś próbował portować aplikację Eclipse RCP na NBPlatform, mechanizmy w środku działają na podobnej zasadzie, ale w przypadku zaawansowanych kontrolek może nie być różowo. Ogromne wrażenie zrobił na mnie Adam Bien (rzeczywiście trzech Adamów na jednej konferencji to całkiem sporo ) generalnie jestem umiarkowanym fanem live-coding, ale poczucie humoru i dynamizm z jakim AB przeprowadził słuchaczy przez arkana NetBeans 6.5 jest godne podziwu.

Tyle merytorycznie… chciałem podziękować chłopakom ze Szczecin JUG, którzy przejechali całkiem spory kawałek żeby się w Poznaniu pojawić, mam nadzieje, że piwo w Stajence wypaliło . Były też osoby z Rzeszowa, Aten no i oczywiście z Poznania (najwięcej z UAM). Oddzielne podziękowania muszą powędrować do koła naukowego studentów informatyki UAM, bez was chłopaki byłaby totalna klapa.

O NetBeans Day napisało już kilka osób:

• Geerthan Wielenga – “Poznan & Gdansk: NetBeans Day, Poland”
• Toni Epple – “NetBeans Days in Gdansk and Poznan” (Tony zrobił również kilka świetnych zdjęć, link dostępny w jego wpisie)
• Adam Bien – opisał swoje wrażenia tutaj i tutaj
• Jacek Laskowski – “Wrażenia po NetBeans Day 2008 w Gdańsku”
• Łukasz Stachowiak – “Po NetBeans day Poznań”
• Leszek Gruchała – “Wrażenia z NetBeans Day w Poznaniu” – (dzięki za słowa krytyki, postaram się coś zrobić z moją “żywością” )
• Miroslav Kopecky – “Poland – NetBeans Day Success”

Miłe jest też to, że nasza inicjatywa została zauważona w portalu java.net

.

Dzięki staraniom Macieja Biłasa, Toniego Epple i Bartka Łopatki Poznań NetBeans Day zostało całkiem nieźle udokumentowane, dzięki.

Geertjan Wielenga opowiada o podstawach NetBeans Platform

Adam Kędziora mówił o swoich doświadczeniach w tworzeniu aplikacji w NetBeans Platform, oraz o uczestnictwie w NetBeans Innovators Grant.

Krótka przerwa na poczęstunek, soczek z grejpfruta, paluszki i ciastka.

Autor tego skromnego bloga, w tle logo Poznań JUG.

Karol Harezlak przygotowuje się do swojej prezentacji.

A tu już Karol w akcji.

Geertjan z pamiątkowym kubkiem Poznań JUG.

Toni w mówił o przenoszeniu istniejących aplikacji na NetBeans Platform.

Pan Epple również otrzymał pamiątkowy kubek prelegenta .

Adam Bien według większości uczestników najbardziej interesująca prezentacja konferencji.

Od lewej: Karol Harezlak, Geertjan Wielenga, Łukasz Stachowiak, Toni Epple.

Plan spotkania przedstawia się następująco:

1. Pierwsze piwko lub kawka – obowiązkowe
2. Prezentację nt. “Evidence Based Scheduling” poprowadzę ja
3. Drugie piwko lub kawka- opcjonalne
4. Dyskusja : jak oceniać czas wykonania zadań programistycznych? jak konstruować realistyczne harmonogramy?
5. Zamknięcie dyskusji i być może jakieś wnioski
6. Bieżące sprawy JUG’a.

Prezentacja potrwa około 20min, reszta w zależności od woli uczestników. Serdecznie zapraszam.

Ten post jest również dostępny na stronie Poznańskiej Grupy Użytkowników języka Java.

Poznań Eclipse Demo Camp odbędzie się 21 i 28 listopada, o godzinie 18:30, w sali nr 13. Centrum Wykładowego Politechniki Poznańskiej (skrzyżowanie ulic Piotrowo i Berdychowo).

Program spotkań jest następujący:

21. listopada

Eclipse Way – czyli w jaki sposób organizowac prace wokół projektu open source
- Krzysztof Daniel (IBM, PP), Bartosz Michalik (IBM, PUT)

g-Eclipse: Access the Power of the Grid – przykład projektu eclipse’owego
- Katarzyna Bylec (PCSS, GIK), Mateusz Pabiś (PCSS)

28. listopada

How big fun OSGI can be? – Jacek Pospychała (IBM)

UC Workbench – przyklad aplikacji RCP – Łukasz Olek (IBM, PP)

Po wykładach przewidziana jest dyskusja będzie się też czego się napić i co zjeść

O drugim spotkaniu możecie poczytać na stronach JUG’a, odbędzie się ono 23 kwietnia o godzinie 18:30 w sali nr 4 budynku PCSS przy ul. Zwierzynieckiej 20 (Poznań). Temat spotkania to : “Zróbmy to szybko” czyli Groovy i Grails w akcji a prowadzący… hmmm .

Znalazłem ostatnio wywiad z Jimmy “Jimbo” Wales’em, szerzej znanym jako “Twórca Wikipedii”. Wales w wywiadzie opowiada o początkach, o szczegółach technicznych związanych z działaniem Wikipedii. Jest też sporo anegdot związanych z społecznością wikipedystów, opowiada o skandalach i o tym jak Wikipedia zmieniła sposób w jaki postrzegamy sieciowe “pospolite ruszenie” . Wywiad przeprowadzili Panowie z
Floss Weekly, przy okazji widać jak szeroka może być tematyka związana z oprogramowaniem Open Source. Floss Weekly to świetny podcast, traktujący właśnie o Free Libre/Open Source Software, polecam również inne “audycję” z tej serii – oczywiście jeżeli nie masz czegoś ciekawszego do słuchania drepcząc rano do pracy

Wracając do samego Wales’a, z radością odkryłem, że wywiad który kiedyś czytałem w Focus’ie jest dostępny online. Stąd pochodzi anedgota o bitwie pod grunwaldem i kilka innych ciekawostek.

Linki: FLOSS#007, wywiad z Focus’a