21 stycznia 2009

Reklama nie zawadzi, jeśli odpowiednio umotywowana (przekonajmy się)

Ja tu dopiero, co wspomniałem o potrzebie rozpoznania uruchamiania testów Groovy z pomocą Apache Maven (Relacja z rozdziału 3. "More Advanced Groovy" z "Beginning Groovy and Grails"), a do mojej skrzynki trafia wiadomość o zmianach na stronie Grails > Maven Integration. Zbieg okoliczności, czy ktoś dba, abym nie stracił zainteresowania Groovy & Grails?! Na razie temat czeka cierpliwie na swoją kolej (która z pewnością nadejdzie - nie dziś, nie jutro, ale na pewno wkrótce).

Dla zainteresowanych przyspieszeniem rozpoznawania Grails natrafiłem na ciekawą prezentację Guillaume Laforge z Devoxx 2008, która trwała...3 godziny (!) Gość ma klasę, jeśli nie tylko potrafi programować, ale również przedstawiać temat w zrozumiały sposób. Dla niezorientowanych wspomnę, że jest on głównodowodzącym projektem Grails. Nie wiem, jak mu poszło, bo nagrania z jego wystąpienia nie ma, ale za to prezentacja jest do publicznej konsumpcji - Groovy and Grails in Action - Devoxx 2008 - University - Guillaume Laforge. Warto, bo nie zabiera wiele czasu (mimo liczby slajdów), a wiedza z samego źródła.

Dzisiaj miałem dwie ciekawostki, które sprawiły, że moje prywatne zainteresowania mogą mieć znaczący użytek służbowy. Podczas dzisiejszej rozmowy na temat IBM WebSphere Business Services Fabric (WBSF) V6.2 z moim podopiecznym, w ramach programu praktyk studenckich w IBM, moją uwagę przykuł jeden URL w aplikacji zarządzającej WBSF - ten, który zawierał w adresie...wicket:bookmarkablePage (!) Tylko mignęło, ale to wystarczyło, abym innym okiem spojrzał na WBSF, chyba nawet trochę przychylniejszym (chociaż i tak było wystarczająco przychylne). Wciąż jeszcze nieznane jest dla mnie biznesowe zastosowanie WBSF, ale sam fakt, że wykorzystuje pod spodem Apache Wicket od razu sprawił, że nie mogę doczekać się wyników mojego studenta, który ma za zadanie przedstawić produkt ze szczegółami. Możliwość połączenia zainteresowań prywatnych z obowiązkami służbowymi sprawia, że to, co człowiek robi w wolnej chwili staje się natychmiast zajęciem służbowym, a to cieszy każdego zawalonego robotą, czyż nie? Oczywiście ma to swoje minusy. Kiedy zainteresowanie staje się obowiązkiem, niewiele dzieli go od stania się ciężarem i znużenia nim. Sądzę, że do znużenia Wicketem nie dojdzie u mnie prędko (aczkolwiek dawno o nim nie wspominałem), a wraz z Groovy czuję, że wiele dobrego mnie czeka. Jeśli mógłbym "pożenić" te technologie w rozwiązaniach służbowych, tym lepiej dla mnie i klientów rozwiązań. Pozostaje tylko wierzyć, że będzie to dla nich równie wartościowym połączeniem, jak dla mnie.

Drugą ciekawostką, o której już wiedziałem od jakiegoś czasu, ale teraz nabrała innego wydźwięku jest IBM WebSphere sMash. Komercyjny aczkolwiek bezpłatny produkt firmy IBM, który oparty jest o otwarty projekt Project Zero. A dlaczego o nim, kiedy powinienem właśnie przedstawić kolejny rozdział książki Beginning Groovy and Grails: From Novice to Professional? sMash jest szkieletem webowym, w którym aplikacje pisze się w PHP oraz...Groovy. Tu wszyscy wstają, klaszczą i rozpoczynamy imprezę! ;-) To jest właśnie ten moment, w którym jednym zamachem, rozpoznając Groovy, można jednocześnie rozpracować kolejny - IBM WebSphere sMash. Cudownie!

Można sobie teraz tylko wyobrazić miny wszystkich tych, którzy byli przeciwni stosowaniu obu technologii jako niedojrzałych lub (co bardziej kuriozalne) otwartych. Zdaje się, że już przynajmniej jeden gigant IT - IBM - postawił na Apache Wicket i Groovy. Czy trzeba więcej argumentów, aby przekonać najbardziej nieprzekonanych kierowników IT, architektów, szefów grup rozwojowych, że komercyjne produkty z płatnym wsparciem oparte są o produkty darmowe, co sprawia, że dojrzałość tych drugich jest wystarczająca do zastosowań komercyjnych? Sądzę, że tym samym odparty został ostatni zarzut o ryzyku wdrożenia obu i jedynym problemem może być wyłącznie nasz brak zainteresowania ich wykorzystaniem. Jeśli nawet miałem wątpliwości wczoraj w kontekście wartości płynących w promowaniu Groovy czy Wicket, bądź jeszcze dzisiaj rano, teraz już całkowicie się ich pozbyłem. Ktoś jeszcze tego doświadczył?

p.s. Nie byłbym sobą, gdybym nie wspomniał, że ten blog został zgłoszony do konkursu Blog Roku 2008. Coś nie może się ruszyć w rankingu przesłanych SMSów i bidulek siedzi na drugiej stronie w kolejności oddanych głosów. Proponuję natychmiast wysłać SMSa o treści B00204 (czytaj: be-zero-zero-dwa-zero-cztery) pod numer 7144 za 1,22PLN brutto i mieć to z głowy. Po co czekać na ostatni dzień?! ;-)

5 komentarzy:

  1. O, a ja myślałem, że "project zero" to jeszcze jest daleko od zastosowań komercyjnych. Nice...

    Mam jednak wrażeniem, że języki takie jak Groovy wymagają lepszych programistów niż np. Java. W Javie można co najwyżej zrobić głupią architekturę. W Groovy można zrobić wszystko głupio ;) (Przynajmniej jednego bardzo dobrego programistę do nadzoru nad resztą)

    Proste rzeczy są możliwe, ale rzeczy niebezpieczne są zbyt proste. Można zdrowo przesadzić z dynamizmem. Jakbym był konsultantem to bym oferował rozwiązania w językach dynamicznych z prostej przyczyny - nikt oprócz mnie nie byłby w stanie bez dokumentacji załapać co tam się dzieje ;)

    Prawdę mówiąc liczba koncepcji, którą Groovy wprowadza jest bardzo duża. Każda koncepcja to potencjalny błąd. Np. multiple dispatch, być może jest przydatny w 99% przypadków, ładny i logiczny. Jeśli się nie wie o tym, to nie sposób znaleźć błędu. Debugowanie również jest trudniejsze w takim języku.

    Groovy jako język dynamicznie typowany zawsze będzie językiem wolniejszym od Java. Samo wywołanie metody podobno jest kilkaset razy wolniejsze (głównie z powodu multiple dispatching), nie wiem ile dokładnie w tej chwili. Scala w pewnych testach wypada nawet szybciej od Javy, mimo to jest ładnym, ciekawym językiem (choć trochę za bardzo zmienili składnie na mój gust).

    Mimo to lubię Groovy i widzę dla niego miejsce ;)

    OdpowiedzUsuń
  2. Najbardziej z prezentacji Guillaume Laforge podobał mi się slajd 10: "Integrated in Open Source projects Spring.... Mule":) a do tego widziałem gdzieś dzisiaj znacznik "groovy" w pliku konfiguracyjnym Mule, więc nic więcej mi nie pozostaje jak rozpoznać temat:)
    PS. SMS wysłany i powodzenia:)
    --
    Pozdrowienia
    Łukasz Lipka
    http://lukaszlipka.blogspot.com/

    OdpowiedzUsuń
  3. Podany numer bloga nie istnieje... be-zero-zero-dwa-zero-cztery. Sprawdzałem parę razy.

    OdpowiedzUsuń
  4. zgadza się, numer bloga nie istnieje ... Jacek zrób coś ;)

    OdpowiedzUsuń
  5. @Krzysiek: Ponieważ ostatnio siedzę w projekcie w całości pisanym w Scali oraz pisałem również aplikacje w Groovy i Grails to uważam, że o ile Groovy i Java są stosunkowo bliskie sobie i tutaj moim zdaniem nie ma specjalnej różnicy w wiedzy jaka jest potrzebna aby pisać aplikacje zarówno w jednym jak i w drugim języku to o tyle w Scali sprawa wygląda zupełnie inaczej, to jest dopiero język który potrafi zmusić do wysiłu, jego konstrukcje i możliwości, które dostarcza potrafią momentami przytłaczać :)

    OdpowiedzUsuń