I mnie okrzyknięto IBM Certified System Administrator - WebSphere Application Server Network Deployment V7.0

Przez ostatnie miesiące, od kiedy rozpocząłem pisanie książki-redbooka "Getting Started with the WebSphere Application Server Feature Pack for Service Component Architecture" (czeka na publikację pod koniec marca) zajmowałem się wytrwale najnowszą wersją serwera aplikacyjnego IBM WebSphere Application Server 7.0. Cudeńko mnie zachwyciło ze swoim wsparciem dla Java EE 5 i innymi świecidełkami, m.in. BLA, CIM, Job Manager i Administrative Agent, że postanowiłem podsumować moją działalność z nim certyfikatem IBM Certified System Administrator - WebSphere Application Server Network Deployment V7.0. Do jego zdobycia potrzebne było zdanie jednego testu Test 000-377 - IBM WebSphere Application Server Network Deployment V7.0 Core Administration, który trwa 1,5 godziny. Dzisiaj się zebrałem i go...zdałem! Jutro teoretyczna prezentacja WAS 7.0 z jego wsparciem dla SCA na Studenckim Festiwalu Informatycznym, więc jak znalazł.

Wynik bardzo zadowalający, bo w końcu osiągnąłem magiczny pułap 75%, co mnie niezwykle naładowało pozytywnym myśleniem, o kolejnych wyczynach certyfikacyjnych :) Uczyłem się głównie praktycznie, podczas rozpracowywania WAS7 pracując z nim (w wersji 7.0.0.7 i SCA 1.0.1.1) na VMware z Linuksem. Część teoretyczna to:

• IBM Education Assistant - IBM WebSphere Application Server Version 7
  
• WebSphere Application Server Version 7.0 Information Center

Polecam oba źródła w tej kolejności, najpierw IEA a później InfoCenter. Są bezcenne. Planowałem zajrzeć do WebSphere Application Server V7: Concepts, Planning and Design, ale jakoś tak na planowaniu się ostało. Ach, w międzyczasie przeczytałem dwie książki o WAS7:

• Pro IBM WebSphere Application Server 7 Internals by Colin Renouf (Apress, Jul 2009)
• WebSphere Application Server 7.0 Administration Guide by Steve Robinson (Packt, August 2009)

Dokładając do tego doświadczenia teoretyczne i praktyczne/projektowe z WAS 6.1 i jakoś tak wyszło, że się zrobiło 75%.

Kolejnym będzie już programowanie Web Services z WAS7 - IBM Certified Solution Developer - Web Services Development for WebSphere Application Server V7.0. Pewnie nie wcześniej niż za 1-2 miesiące, bo postanowiłem sięgnąć po więcej niż 80%, a to dla mnie stanowi nielada poprzeczkę (znajomi robią 100%, a mnie 80% zadowala).

Już pisałem o tym, ale powtórzę - w końcu IBM doczekał się serwera, który nie odstaje możliwościami darmowym rozwiązaniom w stylu JBoss AS czy GlassFish. One od dawna były na poziomie Java EE 5, a WAS dopiero od wersji 7.0, czyli od pół roku. Świat od razu wydaje się bardziej kolorowy. Jakby to było jeszcze cudniej, gdyby tak każdy klient chciał zmigrować na WAS7. Zgłaszam się na ochotnika, aby pomóc...za kaskę oczywiście! :)

Praktyki studenckie w IBM - ta edycja będzie nowatorska pod każdym względem - technologicznie i komunikacyjnie

Rozpoczęły się kolejne praktyki studenckie w IBM, które w edycji wiosennej trwają 3 miesiące, od marca do końca maja. Student wybiera temat z puli tematów, które do bazy wprowadzają potencjalni mentorzy (zainteresowani rolą mentora pracownicy IBM) z opisem swoich wymagań odnośnie proponowanego tematu. To trochę tak, jak z pracą licencjacką (nie robiłem, więc nie piszę z własnego doświadczenia, ale domyślam się, że tak jest), czy pracą magisterską (robiłem kilka, jedną ukończyłem, więc wiem :)). Promotorzy szukają studentów, albo odwrotnie i tak samo jest w programie IBM - Educational Student internship Program (w skrócie IBM ESI). Mnie interesują głównie rozwiązania z zastosowań produktów rodziny IBM WebSphere i staram się je wprowadzać w głowy młodych-gniewnych z rozwiązaniami otwartymi (o których mogę później pisać na blogu, jakbym się na nich znał i rozpoznał samodzielnie :)). Obie strony zyskują - IBMer (w tej roli ja) poznawanie nowych obszarów, na które nie miał czasu, a student-praktykant sposób pracy IBMera, wejście w tematy z "górnej półki" i pewnie cała masa innych rzeczy, którymi napycha się CVki. W końcu chodzi o wypromowanie obu - produktu i praktykanta, aby obaj mogli znaleźć się na rynku. Widzę jedynie plusy tego rozwiązania, więc kiedy dowiedziałem się o kolejnej edycji, nie miałem złudzeń i od razu krzyknąłem "Wchodzę!".

Wspominałem niejednokrotnie o tym, że unikam promowania pracodawcy, aby nie być posądzonym o stronniczość, brak dystansu, itp., więc niewiele można o nim tutaj przeczytać. Na razie niech tak zostanie, ale o praktykach nie mogę nie wspomnieć, bo temat jest w pełni jawny (dosłownie i w przenośni). Każdy student uczelni wyższej w Polsce i zagranicą może skontaktować się z prowadzącym program (nazwiska świadomie nie podam, a jedynie na życzenie) i wybrać temat (i jednocześnie prowadzącego).

Szaty mentora przybierałem już kilkanaście razy (przynajmniej 12) i głównie pracowałem z osobami z uczelni warszawskich. Trafiło mi się raz prowadzić 2 studentów z Serbii, ale wyniki były tak kiepskie, że prawie sam się załamałem i bodajże 1-2 osoby spoza Warszawy. Zawsze jednak liczba jednocześnie prowadzonych studentów-praktykantów nie przekraczała 2, każdy z osobnym tematem.

Tym razem jest zdecydowanie inaczej. Nie tylko że jednocześnie prowadzę 3 studentów, każdy pracujący samodzielnie, ale jeszcze wszyscy są zdalni! 3 osoby z Zielonej Góry. Tego jeszcze nie próbowałem, a kiedy napiszę, że zaraz wdrożyłem niecny plan poprowadzenia ich trybem "zwinnym" (nazwa robocza), to nie mam już złudzeń, że będą to najbardziej intrygujące praktyki, jakie do tej pory prowadziłem. A przecież jeszcze nie wspomniałem o tych wybranych tematach - też cudne:

• Creating user interface for Human Tasks in IBM WebSphere Process Server V7 with Grails
• Using Kerberos token profile to secure enterprise applications in IBM WebSphere Application Server V7
• Installation of new versions of a BPEL process, and allowing the migration of running processes to a new version in IBM WebSphere Process Server V7 and JBoss Seam-based client

Mój "zwinnie nowatorski" sposób na praktyki z 3 osobami zdalnie, każdy indywidualnie ze swoim tematem, wygląda następująco:

• Każdy podopieczny pracuje na Linuksie (RHEL lub SLES - certyfikowane dystrybucje dla produktów WebSphere) na VMware (na wypożyczonych laptopach mają Windows i szkoda byłoby marnować czasu na przeinstalowywanie systemu, a i późniejsze przekazanie pracy jest łatwiejsze - dostaję dokumentację z gotowym obrazem). W ten sposób poznanie produktu od strony administracyjnej jest dokładniejsze, bo praca z linią poleceń na MS Windows to jak stąpanie po kruchym lodzie - można się załamać.
  
• Temat dzielony jest na części tak, aby można było skończyć go w ciągu tygodnia/dwóch. Są to tak proste zadania, jak instalacja, pierwsze próby z przykładowymi aplikacjami, ale i bardziej wyrafinowane, jak rozpoznanie działania produktu w danym obszarze, czy połączenie rozwiązania komercyjnego z darmowym, np. WPSa z Grails, Apache Wicket czy JBoss Seam. Tematy łączą przyjemne (Grails, Wicket, Seam) z pożytecznym (WPS) :). Na końcu prac tworzona jest dokumentacja opisująca co i jak autor miał na myśli.
  
• Nauka głównie z ogólniedostępnych materiałów - IBM Education Assistant czy Information Center dla danego produktu, np. WAS7 InfoCenter, WPS7 InfoCenter, WID7 InfoCenter.
  
• Śledzenie postępów prac przez...bloga, twittera i blipa! W każdy piątek zdzwaniam się z praktykantem (najpóźniej w środę wysyła mi zaproszenie z wybraną godziną między 10-14) i przez najwyżej 1h omawiamy co zostało zrobione i co planujemy. Omawiamy problemy i ich rozwiązania (albo ich brak i wtedy szukamy miejsc, gdzie można je znaleźć). Podsumowanie naszych rozmów trafia na bloga (więc przynajmniej jeden wpis pojawia się tygodniowo) z wpisami na blipa (po polsku) i twittera (po angielsku) o codziennych postępach prac w odpowiednich kanałach. W ten sposób ja wiem, co się dzieje, a praktykanci rozgłaszają swoje nabywane umiejętności (co może przypominać Inversion of Control, gdzie to nie oni szukają zatrudnienia, ale ich się znajduje przez ich publiczną aktywność - zgodnie z zasadą Demeter zwaną również Hollywood Principle: "Nie dzwoń do nas, my zadzwonimy do Ciebie"). To powinno również wymóc na praktykantach dzielenie podejmowanych zadań na cząstki, które da się zrealizować w ciągu godzin i opisać w 144 znakach.

Właśnie ten ostatni element jest dla mnie najbardziej intrygujący. Reszta była już wałkowana kilkakrotnie przedtem i nie jest dla mnie wielkim novum. Niezwykle ciekawym wyników.

Namiary na 2 pierwszych praktykantów (na razie konta na twitterze):

• Andrzej Ludwikowski (aludwikowski)
• Marek Szpak (marekszpak)

Nie pozwólcie im sądzić, że ich praca jest niezauważona przez społeczność :)

Jak Wam się podoba takie podejście do tematu? Moglibyście coś zasugerować, abym mógł poczuć klimaty zdalnego prowadzenia zespołów programistów w zwinnym stylu i nowymi technologiami (w tym i komunikacyjnymi)? Ciekawe, czy dałoby się tak prowadzić firmę?

Grails a TDD z perspektywy "Growing Object-Oriented Software, Guided by Tests"

Książka jest od dzisiaj obowiązkowa dla kogokolwiek, komu przyjdzie pracować ze mną, aby...zrozumiał moje postępowanie :)

Rozpocząłem rozdziały praktyczne w części Part II. The Process of Test-Driven Development i nie mam wątpliwości, że teoria, a teraz praktyka (wciąż jednak tylko w postaci lektury książki), pozostawią trwały ślad w moim postrzeganiu programowania. Uległem książce całkowicie i czuję się lekko rozdarty.

Z jednej strony książka nawołuje do rozpoczynania projektów od przekrojowych testów integracyjnych, gdzie testuje się wybrane funkcjonalności docelowej aplikacji...bez jej istnienia (chociażby jednej maluczkiej klaski), a z drugiej mam świadomość (albo i nie, ze względu na brak praktycznego doświadczenia), że potrzebna wiedza na początku projektu i do zrobienia tego pierwszego kroku jest niebagatelna, a nerwy trzeba trzymać mocno na postronku. Moje rozpalone są do czerwoności. Chciałoby się trochę poszaleć programistycznie, a tu każą uzbroić się w cierpliwość i zbudować szkielet testujący wybraną funkcjonalność. I nie ma to być trywiał w stylu odczyt z bazki, ale w przypadku aplikacji webowej, najlepiej uruchomić przeglądarkę, wskazać właściwą stronę i sprawdzić wynik! Dla mnie to novum, bo pisanie testów sprowadzałem zwyczajnie do testów jednostkowych, jeśli w ogóle.

W przypadku Grails sprawa się znacznie upraszcza, bo wykonanie dowolnego polecenia budującego typu grails create-controller czy grails create-domain-class tworzy nie tylko wskazany artefakt, ale i...test integracyjny (!) Człowiek, czy chce, czy nie, ugrzązł w TDD na dobre. To, czy wyjdzie to na dobre i czy w ogóle skorzysta się z tego dobrodziejstwa jest tematem na inne przemyślenia, ale fakt faktem Grails zdaje się być pomocnym. Czy aby rzeczywiście można nazywać to "pomocnym"?

I tu pojawiła się moja wątpliwość. Nawet, jeśli Grails faktycznie tworzy testy integracyjne dla wybranego artefaktu czy stworzymy go explicite z grails create-integration-test, to zastanawia mnie, czy to faktycznie odpowiada początkowemu testowaniu integracyjnemu z TDD jak opisano w tej książce. Zdanie z dokumentacji grails create-integration-test:

An integration test differs from a unit test in that the Grails environment is loaded for each test execution.

uspokaja mnie nieznacznie, bo w końcu cała infrastruktura Grails jest uruchamiana w całości przy każdym teście, ale zastanawiam się, czy nie powinienem raczej zbudować war (grails war), uruchomić Tomcata z podłączoną zewnętrzną bazą danych, wdrożyć i uruchomić aplikację i po uruchomieniu przeglądarki uruchomić testy integracyjne (pewnie z pomocą Selenium)?! Znacznie to więcej roboty, ale faktycznie odpowiada bardziej docelowej architekturze, a tak zrozumiałem potrzebę rozpoczęcia prac z testami integracyjnymi, które najbardziej zbliżą nas do docelowego środowiska produkcyjnego. Czy przypadkiem nie poniosło mnie za bardzo? Pomocy!

SpringSource Tool Suite (STS) i niewidoczny katalog domowy Grails pod Mac OS

Trochę mnie to zaskoczyło i wciąż nie mogę uwierzyć, że tak to działa. Jak się przekonałem, niuanse systemowe Mac OS mogą wprowadzić w pewne zakłopotanie.

Pod Mac OS niektóre katalogi są ukryte w menedżerze plików Finder, np. /usr/local.
Zwykłem instalować własne oprogramowanie właśnie w /usr/local i tak też zrobiłem z Grails 1.2.1. Siedzi sobie grzecznie w /usr/local/grails.

 devmac:~ jacek$ type grails
 grails is hashed (/usr/local/grails/bin/grails)

"Nielada problem" możnaby powiedzieć. Kiedy przyszło mi konfigurować Grails w SpringSource Tool Suite (STS) pojawił się problem z niewidocznością /usr (pola Version i Grails home są tylko do odczytu)!
Nie mam bladego pojęcia, jak to rozwiązać poprawnie(j), ale u mnie wystarczyło podlinkować katalog /usr/local/grails na dowolny inny w widocznym katalogu i jego wskazać jako katalog domowy Grails.

 devmac:~ jacek$ ln -s /usr/local/grails grails

Wskazując na niego, wejdziemy do wskazywanego (ukrytego w Finder).
I Eclipse jest szczęśliwy, ale nie bardziej niż ja :)

Może być potrzebne odświeżenie zależności w projekcie, jeśli Grails został zdefiniowany po jego imporcie - menu kontekstowe Grails Tools > Refresh Dependencies.
Wtedy pojawi się wirtualny katalog w projekcie Grails Dependencies [Grails], gdzie jak rozumiem to, co występuje między nawiasami kwadratowymi jest nazwą, którą podałem podczas definiowania katalogu domowego Grails.

Oczywiście po wykonaniu tej sztuczki katalog ~/grails nie jest już potrzebny i można go skasować. Problem rozwiązany, ale wciąż pozostaje pytanie, czy nie ma prostszego rozwiązania. To wydaje mi się lekko przekombinowane.

p.s. Dla spragnionych wrażeń: istnieje możliwość włączenia opcji wyświetlania wszystkich plików i katalogów w Finder - więcej w artykule Show all files in the Finder.

63. spotkanie Warszawa JUG - Jacek Szczukocki z "JGAP, czyli gen javy w każdym z nas"

Warszawska Grupa Użytkowników Technologii Java (Warszawa JUG) zaprasza na 63. spotkanie, które odbędzie się we wtorek, 9. marca o godzinie 18:00 w sali 5440 Wydziału MIM UW przy ul. Banacha 2 w Warszawie.

Temat: JGAP, czyli gen javy w każdym z nas
Prelegent: Jacek Szczukocki

Algorytmy genetyczne (GA's) są algorytmami wyszukiwania, które działają w procesie doboru naturalnego. Rozpoczynają się od zestawu możliwych rozwiązań, który następnie ewoluuje w kierunku zestaw bardziej optymalnych rozwiązań. W zestawie rozwiązań te, które są słabe zazwyczaj wygasają podczas, gdy lepsze rozwiązania są propagowanie ich korzystne cechy, wprowadzają więcej rozwiązań do zestawu, który oferują większe możliwości (czy tu nie ma jakiegoś błędu językowego? to jeszcze mutuje :)). Przypadkowe mutacje pomagają zagwarantować, że zestaw ten nie popadnie w stagnację.

Prezentacja ma na celu zainteresowanie słuchaczy tematyką wykorzystania systemów sztucznej inteligencji, a w szczególności algorytmami genetycznymi. W trakcie prezentacji opiszę zasadę działania oraz podstawy biologiczne algorytmów genetycznych oraz innych technologii wchodzących w skład szkieletu JGAP. Prezentacja obejmie przykłady z wykorzystaniem algorytmów genetycznych z naciskiem na ich mocne i słabe strony.

Jacek Szczukocki jest absolwentem Wydziału Informatyki katedry Systemów Sztucznej Inteligencji i Systemów Ekspertowych Wyższej Szkoły Humanistyczno-Ekonomicznej w Łodzi. Programista Java od 4 lat. Zafascynowany technologią sztucznej inteligencji i zagorzały propagator jej wykorzystania..

Planowany czas prezentacji to 1,5h, po której planuje się 15-30-minutową dyskusję.

Wstęp wolny

Zapraszam w imieniu prelegentów i grupy Warszawa JUG!

"Nie ma geniuszu bez ziarna szaleństwa" - "wątpliwa" lektura o TDD z "Growing Object-Oriented Software, Guided by Tests"

O Test-Driven Development (TDD) każdy gdzieś tam słyszał i niejeden obiecywał wdrożenie jego zasad. Jednym się udaje (albo sądzą, że tak jest), a inni polegli i zarzucili temat. Smutna prawda, ale prawda. Pewnie w dużej mierze dlatego, że pomimo wiadomych zysków - przede wszystkim skoncentrowanie na celu, jakim jest stworzenie działającego oprogramowania, zamiast rozdmuchiwania modelu, później kontrolerów, później widoku i jeszcze tysiąca innych warstw, aby ostatecznie przekonać się, że połowy nie potrzebowano, albo że i tak nie wiadomo, po co i na co, a termin i klient dawno poszli w zapomnienie - wdrożenie takiego podejścia wymaga niezwykłego zdeterminowania zespołu do zrealizowania postawionego celu. Innymi słowy - rygoru i dyscypliny! A kto by tam lubił rygor i dyscyplinę?! Niewielu osobom kojarzy się to z czymś przyjemnym. Mi na pewno nie.

Po recenzji Tomka Kaczanowskiego "Growing Object-Oriented Software Guided by Tests - Book Review" i namowie Bartka "Koziołek" Kuczyńskiego (Fwd: A free copy of "Growing Object-Oriented Software, Guided by Tests" for review doable?), aby ją zamówić do Biblioteki Warszawskiego JUGa dotarła i do mnie. W zeszłym tygodniu rozpocząłem jej lekturę i...jestem pod ogromnym jej wrażeniem. Niesamowicie nabałaganiła w mojej głowie. Stąd to użycie słowa "watpliwa" w tytule wpisu, bo narodziło mi się wątpliwości cała masa (i oby nie zakończyło się psychiatrą :)).

Książkę "Growing Object-Oriented Software, Guided by Tests" panów Steve Freeman i Nat Pryce (Oct 12, 2009 by Addison-Wesley Professional) czyta się lekko i przyjemnie. Jestem przy rozdziale 11. "Passing the First Test" (z 27-miu i 2 dodatków), więc praktycznie (dosłownie i w przenośni) niewiele mogę o niej napisać, ale mimo jej początkowego namolnego przekonywania o wyższości TDD nad tradycyjnym podejściem do tworzenia oprogramowania (najpierw model, później interakcje w jego ramach z testami jednostkowymi w międzyczasie), widać jedną wyraźną różnicę w moim postrzeganiu TDD, a tym, co autorzy rozumieją pod tym akronimem.

Do tej pory sądziłem, że TDD to przede wszystkim testy, co jest do tego momentu prawdziwe. W moim jednak rozumowaniu były to przede wszystkim testy jednostkowe przy tworzeniu konkretnych klas (dowolnej warstwy). W tej książce dowiedziałem się prawdy i to nie takiej, jakiej oczekiwałem początkowo. Miałem świadomość różnic w moim postrzeganiu TDD a jego zasadami, głównie z braku praktycznego doświadczenia i niezbyt dalekoidącym zainteresowaniem tematyką, ale to, w jaki sposób TDD przedstawia ta książka przeszło moje najśmielsze oczekiwania. Sprawa rozbija się o te "nieszczęsne" testy. Książka podzielona jest na 5 części, z których pierwszą mam już za sobą Part I. "Introduction", w której dowiedziałem się o teorii TDD i testach...funkcjonalnych, ale nie takich, które weryfikują przydatność gotowego produktu przez klienta (prawdopodobnie wykonanych wspólnie z nim manualnie), ale takich, które zweryfikują automatycznie, że dana funkcjonalność jest gotowa do testowania końcowego z klientem (!) To było dla mnie zabójcze doświadczenie, kiedy dodać do tego, że owe testy tworzy się zanim cokolwiek w naszej aplikacji powstanie, nawet infrastruktura. Czyż to nie (sarkazm włączony) "odświeżające" podejście (sarkazm wyłączony)?!

Zatem, jeśliby potraktować podejście książkowe, to zaczynamy od przekrojowego testu wybranej, pierwszej, zwykle łatwej do osiągnięcia, funkcjonalności końcowej aplikacji. Nie piszę tutaj o testach klasy XYZ, czy testach użyteczności technologi ABC, ale o pokrojeniu całej ostatecznej aplikacji (znanej na bazie dotychczasowych wymagań klienta) na kawałki funkcjonalne - rozpoczynające się od interfejsu użytkownika, a kończące się na systemach wewnętrznych - i bez rozstawionej infrastruktury stworzenie dla wybranego kawałka testu. Z oczywistych względów nie będzie to działający test - nic nie mamy - ale właśnie o to chodzi. Tylko, który zespół to wytrzymuje?! Chyba tylko te najbardziej zdeterminowane, zdyscyplinowane i...tu należałoby dopisać inne zalety zespołów, o których istnieniu nie miałem pojęcia. Jeśli takie istnieją, koniecznie muszę się dowiedzieć o ich stanie duchowym, kiedy nic nie ma, a trzeba stworzyć dla tego czegoś nieistniejącego kod testujący, w którym czerwonego więcej niż czarnego (czerwone to podkreślenie błędu w IDE, a czarne to wpisane litery składające się na test). W/g mnie praca w takim zespole może być tylko przywilejem, a dostosowanie się do reguł TDD...szaleństwem. W tym ujęciu jednak "szaleństwo" jest dla mnie czymś niezwykłym i zagadkowym. "Choć to szaleństwo, jest w nim przecie metoda" powiedział William Shakespeare w Hamlecie, ale podobają mi się też takie powiedzenia (zaczerpnięte z Wikicytaty) - "Kto ukrywa własne szaleństwo, umiera niemy" czy "W szalonym świecie tylko szaleńcy są rozsądni" i "Nie ma geniuszu bez ziarna szaleństwa". Naczytanie się takich powiedzonek nie może pozostać obojętne na nasze postrzeganie świata i podobnie jest z tą książką.

Zgodnie z nią, pierwsza faza TDD to stworzenie testu przekrojowego zwana The Walking Skeleton. Ów "chodzący szkielet" to szkielet przyszłego rozwiązania funkcjonalnego. Jego zadaniem jest sprawdzenie naszej świadomości architektonicznej tworzonej aplikacji i zaproponowanie architektury docelowej. Najlepiej jest, aby test był niewielki, ale dotykał wszystkich warstw, począwszy od interfejsu końcowego użytkownika a skończywszy na systemach zewnętrznych. W książce tworzony jest system aukcyjny jako samodzielna aplikacja desktopowa w JFC/Swingu i komunikująca się przez XMPP (w tej roli Smack) z płatnym systemem aukcyjnym. Do testowania GUI w Swingu wykorzystuje się WindowLicker, o którym nigdy wcześniej nie słyszałem (co, choćby z tego tylko powodu, już stanowi wartość z czytania tej książki). Dopiero w rozdziale 11. "Passing the First Test" przekonam się, jak autorzy zestawiają całe środowisko, więc nie napiszę, co o takim podejściu myślę teraz, poza tym, że jestem równie zdruzgotany, jak niewiele wiedziałem o TDD, jak zaintrygowany nowatorskim podejściem do tworzenia oprogramowania. Oby mi się nie udzieliło, bo nieznającym tematu ciężko będzie zrozumieć...szaleńca :)

Na bazie doświadczeń z tej książki chciałbym zrealizować pewien swój pomysł na aplikację desktopową z GUI w JFC/Swingu. Jednym z problemów, z jakim się obecnie borykam, to wybór między Eclipse RCP a NetBeans RCP. O tych słyszałem, że warto je rozważyć, ale może są inne? Chciałbym, aby tworzenie GUI było równie proste, co ostatnio stworzona przeze mnie aplikacja w Objective-C/Cocoa w Xcode na bazie lektury Introduction to Cocoa Application Tutorial. To było tak niezwykle proste, że uwierzyłem w swoje ukryte pokłady wiary na powrót do C w wersji obiektowej i na MacOS :) Nie chciałym jednak wchodzić w ten temat, kiedy tworzę aplikację GUI przede wszystkim na MS Windows i Linuksa, a Mac OS przy okazji, więc pewnie wybór padnie na Eclipse RCP vs NetBeans RCP. Jako, że nie chciałbym wracać do silnie typizowanego programowania w Javie i Swingu, więc przyjdzie mi skorzystać z Griffon, który jest (jak rozumiem) połączeniem NetBeans RCP i Groovy. Jak się coś nawinie z Clojure może zrobię przeskok, ale na chwilę obecną tnę moje żądze do realizowalnego minimum.

A jak Wam idzie TDD z tworzeniem aplikacji desktopowych w JFC/Swing, NetBeans RCP czy Eclipse RCP? Co polecacie na warsztat? Gdyby jeszcze było na tyle lekkie, aby dało się to puścić przez Java Web Start byłoby cudnie (aczkolwiek jest to wymaganie niewielkiego znaczenia).

Sun Education Open Day - zaproszenie na warsztaty certyfikacyjne

To już druga inicjatywa Suna...ekhm...Oracle i kiedy się o niej dowiedziałem od razu zaproponowałem jej publikację na swoim blogu. Darmowe inicjatywy wspierające społeczność javową zawsze mile widziane!

Zanim zaproszenie, jedna uwaga - w tym samym terminie jest konferencja 4Developers w Poznaniu, na której wystąpię z tematem Modele komponentowe SCA, OSGi, Distributed OSGi i OSGi Enterprise a Java EE. Pozostaje jedynie mądrze wybrać :) Ja już mam to za sobą.

Warsztaty certyfikacyjne - Java
26.03.2010 Warszawa

Sun Learning Services zaprasza wszystkich zainteresowanych na warsztaty z zakresu Javy. Celem spotkania jest zapoznanie się z nowościami w Javie, sprawdzenie się na próbnych testach egzaminacyjnych, otwarta dyskusja z instruktorami i innymi uczestnikami spotkania, jak również zapoznanie sie z możliwościami szkoleniowymi.

Głównym gościem panelu poświęconemu Javie będzie Luc Duponcheel - jeden z najbardziej doświadczonych instruktorów Javy. Szkolenia prowadzone przez Luca cieszą się ogromnym zainteresowaniem. Nasz gość poprowadzi warsztaty o nowościach w Javie 6, jak również w kuluarach poprowadzi dyskusję o certyfikacji SCEA.

Szczegółowe informacje o spotkaniu na stronie www.javapoint.pl (najlepiej zajrzeć tam dopiero od poniedziałku, 8.03).

Gorąco zachęcamy wszystkich tych, którzy interesują się certyfikacją i chcieliby spotkać się z ludźmi o podobnych zainteresowaniach.

Sesja jest bezpłatna.

Pytania prosimy kierować na ses_pl@sun.com
Rejestracje przyjmujemy do 19. marca 2010 - liczba miejsc jest ograniczona!