15 grudnia 2009

Kirk jeszcze w Polsce, ale spotkanie Warszawa JUG z nim już za nami

Właśnie wróciłem z 58. spotkania Warszawa JUG, którego gościem był Kirk Pepperdine i co by tu nie mówić było...pouczająco. Gość znany w światku javowym, więc nie ma co przedstawiać. Od wielu lat boryka się z klientami, którzy z kolei borykają się z wydajnością aplikacji javowych i zebrał już spore doświadczenie, aby przedstawiać tematy wydajnościowe w świecie. Zawitał i do nas dzięki uprzejmości SUN Microsystems Poland (w osobie Oliwi Łączyńskiej) i Grzegorza Dudy. Skoro na spotkaniu pojawił się duży gracz - Sun - nie zabrakło i dodatków w stylu pizza i napoje, co o tyle mnie zaskoczyło, że nie minął kwadrans a po 20 pizzach XXL zostały tylko opakowania. Zanim skończyłem robić kilka filmików, jak to się ludziska delektują, po pizzy ni widu ni słychu (może to i dobrze, bo wyglądała na smaczną, a pewnie zjadłbym jej więcej niż powinienem). Później dojechała kolejna partia pizz, która też zniknęła w mgnieniu oka. Na koniec Oliwia rozdała zarejestrowanym koszulki, a wcześniej rozesłała wiadomość o certyfikacji Java z odpowiednim rabatem. Mała rzecz, a cieszy.

Zaczęliśmy prezentację kwadrans po 18tej. Zebrało się dobrze ponad 100 osób (!), co z zarejestrowanych 154 daje "obecność ratio" na poziomie 75% (przypominam, że było ponad 100 osób i z moim optymizmem 75% wydaje się być właściwe).

Bardzo podobał mi się styl prezentacji Kirka, w której doświadczyłem pragmatycznego podejścia do rozwiązywania problemów wydajnościowych w Javie. Zdaniem Kirka, analiza kodu źródłowego ma być ostatnim krokiem w tym procesie, jeśli w ogóle kiedykolwiek do niej dojdzie. Był przykład użycia jps, visualvm i hpjmeter, więc koniecznie należy się w te narzędzia zaopatrzyć przed kolejnym wdrożeniem produkcyjnym :) Oporni z pewnością odczują swoje nieprzygotowanie.

Jakkolwiek Kirk nalegał na większą interaktywność spotkania, czy to przez zadawanie pytań, czy prowokowanie do nich, to jednak widać było opór publiczności przed angażowaniem się w dyskusje po angielsku. Mimo ciągłego narzekania na spolszczanie terminów angielskojęzycznych i przywoływanie znajomości angielskiego w naszej branży, zauważyłem brak dyskusji i mam wrażenie, że właśnie z powodu języka, aczkolwiek nie oznacza to, że nie próbowano. Po prostu było jej zbyt mało, jak na liczność uczestników i tematykę, która aż prowokowała do niej. Miałem wrażenie, że wielu bardzo chciało, ale niestety obawa przed przygotowaniem angielskiego była mocniejsza. A szkoda, bo nawet "wystawienie się na strzał" ze znajomości angielskiego mogłaby być ciekawym doświadczeniem, po którym otwarlibyśmy się na tego rodzaju dyskusje. Zdaje się, że wiedzy nam nie brakuje i na prelegentów zagranicznych nie mamy co narzekać - pojawiają się stosunkowo regularnie - więc jedyne, co pozostaje zrobić, to przełamać lody z angielskiego. Odnotowane jako zadanie na 2010.

Skończyliśmy spotkanie około 20tej i przenieśliśmy się do Jeff's na Polach Mokotowskich. Ludziki po piwku, ja soczek i tak po gorliwych dyskusjach nt. technologii javowych typu Grails i rozwiązań IBM o 22ej rozeszliśmy się do domów. Kirk zgromadził wokół siebie kilka osób, ja zasiadłem po drugiej stronie stołu, gdzie była inna grupka, więc u nas było o Grails i WPSie czy WMB, a u nich pewnie wiało nudą wydajnościową :) Dobrze, od czasu do czasu słuchać zamiast mówić. Widać, że Łukasze (nazwiska znane redakcji) nie czują do końca języków dynamicznych i bałagan i brak doświadczenia zespołu chcą ratować statycznietypowaną Javą. Trzeba będzie dokończyć dyskusje kolejnym razem.

Uważam, że tego typu spotkań powinno być znacznie więcej (tych z zagranicznymi osobami, jak i tych w Jeff's czy innych pubach). Pozwalają zorientować się w naszych mocnych/słabych stronach, i jak w moim przypadku poznać narzędzia, które dostępne są pod ręką (jps, visualvm), ale chyba dlatego, że są tak blisko nie są tak atrakcyjne. Podobnie odświeżające dla mnie było użycie klas z java.util.concurrent, których nie dane mi było użyć. Przekonałem się, że wiele traciłem, skoro podczas prezentacji Kirka, profilowana aplikacja zeszła z 20 sekund do kilku, m.in. poprzez ich użycie.

Nagranie ze spotkania niedługo pojawi się w Sieci, a wszystkim spragnionym relacji fotograficznej polecam zdjęcia w albumie "Kirk Pepperdine na spotkaniu Warszawa JUG".

30 komentarzy:

  1. Wiało nudą powiadasz, rozmawialiśmy o Facebooku, web 3.0, jak się mówi "na zdrowie" po węgiersku, rzeczywiście nudne tematy w porównaniu do Grails i W-cośtamach :P. Nawet jeśli siedzieli tam tacy nudziarze jak ja to był jeszcze Kirk który uratował sytuacje :)

    Z innych fajnych map to zajrzyj tutaj http://blogs.azulsystems.com/cliff/2007/03/a_nonblocking_h.html. To jest dopiero mapa nad mapami, Kirk o niej minimalnie wpomniał na wykładzie (to ten żart że ma tylko 2 procesory więc ConcurrentHashMap będzie ok, bo gdyby miał więcej niż 32 to) :)

    OdpowiedzUsuń
  2. Mi się wykład jak najbardziej podobał. Szkoda tylko, ze usiadłem w ostatnim rzędzie i nie bylem w stanie przeczytać 2/3 slajdów.

    Co do spotkania w Jeffsie to musze przyznac ze Kirk to naprawdę wyluzowany koleś. Tak jak Pedro napisał, po tej stronie stolika na pewno nudno nie było:) Egészségedre!

    OdpowiedzUsuń
  3. "brak doświadczenia zespołu" - skąd ci to przyszło do głowy ??? Czyżby Grails pozwalał usunąć ten "problem"?

    "Nie musisz mieć doświadczonych programistów, Grails załatwi wszystko za nich! Prawdziwy święty graal!!!" :D :D :D

    OdpowiedzUsuń
  4. Mała prośba związana ze zdjęciami - możesz wycinać duplikaty i mało ostre zdjęcia (chyba, że na Macu się nie da :D ) ?

    OdpowiedzUsuń
  5. @Łukasz, "brak doświadczenia zespołu" - a jak inaczej wytłumaczyć poleganie na statycznym typowaniu jako panaceum na błędy, które mogą się pojawić przy programowaniu w Groovy? Dla mnie, to jakby to nie nazwać, zawsze sprowadzi się do doświadczenia. Podobnie w Javie, ale zauważyłem, że bliżej Ci do Javy (vs Groovy), bo mamy statyczne typowanie i dużo za nas wyłapie kompilator. Kilka rzeczy na pewno, ale przekreślać Groovy w dużych projektach (tego nie ustaliliśmy, co to oznacza) bo jest dynamiczny, z tym się nie mogę zgodzić.

    Zdjęcia zostawiłem jak idą, aby inni mogli wybrać, co lepsze dla siebie. Dla mnie zamazane i do kosza, a dla innych bezcenne. Zostawiam do osobistej decyzji przez oglądających.

    OdpowiedzUsuń
  6. @pedro, kris, z tą nudą, to był prztyk w Waszą stronę, aby się dowiedzieć, co tam tak Was zajęło :P

    OdpowiedzUsuń
  7. Statyczne typowanie to jedno z wielu narzędzi jakie pozwalają ograniczyć błędy programistów. Pozbywanie się go dla wygody pisania jest błędem.

    Ja nie przekreśliłem Grails'ów w dużych projektach (odpowiadających użyciu korporacyjnej Javy) - to jest po prostu zbyt niedojrzała technologia, aby podejmować takie ryzyko. Zmiany między 1.1 a 1.2 są znaczne co tylko obrazuje, że ta technologia ciągle się kształtuje i nie wiemy jak będzie wyglądać za 2,3,4 lata.

    Do czego na początku używana była Java? Applety na stronach WWW i przebyła długą drogę, aby zyskać sobie zaufanie korporacji ;-)

    OdpowiedzUsuń
  8. @Jacek : Tak wiem wiem, szkoda że nam Krisa zabrałeś bo miał ochotę dłużej posiedzieć.

    @Łukasz : Nie do końca się zgadzam z zaletą statycznego typowania. Druga rzecz to Grails to nie tylko statyczne typowanie.

    Swoją drogą mogłoby powstać ciekawe spotkanie przy piwie zwolenników statycznego typowania oraz zwolenników dynamicznego typowania wchodzicie w to ?

    OdpowiedzUsuń
  9. @Predo zgadza się nie musisz, ale jakiś rzeczowy argument byłby lepszy ;-)
    Wiem, że Grails to nie tylko "dynamiczne typowanie", ale brak statycznego typowania jest dla mnie największą wadą. Już wolę Scalę chodź jeszcze nie napisałem kawałka kodu ;-)

    OdpowiedzUsuń
  10. @Lukasz

    To mnie spredrowałeś :). Przepraszam, nie podałem argumentu bo nie chciałem wojenki zaczynać, dwa w google jest mnóstwo za i przeciw, więc już w mojej głowie sprawa ta ma podobny charakter jak położenie {}, czyli kwestie upodobań.

    Wezwany do odpowiedzi powiem jak ja to widzę. Otóż statyczne typowanie nie daje mi nic.

    Odwracając pytanie co daje mi statyczne typowanie, to że kompilator wyłapie mi x rodzajów błędów ( gdzie to x jest względnie małe), tutaj osobiście wole narzędzia do statycznej analizy kodu (taki lepszy kompilator) np. findbugs które znajduje wiele więcej ciekawych kalafiorów, a rozszerzenie go o "warning" (nie wiem czy to Jacek przeżyje) "uwaga przypisałeś typ A na typ B" można zrobić samemu jako rozszerzenie findbugs.

    Swoją drogą widzę więcej korzyści z wbudowaniu w javac findbugs niż to że jestem przymuszany do różnego rodzaju konwersji typów bo inaczej kompilator mnie skrzyczy.

    OdpowiedzUsuń
  11. @Łukasz: Hmm może coś w tym jest ale w pracy mam Łukasza który też jest za statycznym typowaniem. Czy istnieje Łukasz który jest przeciw, od dziś to pytanie zadam każdemu Łukaszowi :)

    OdpowiedzUsuń
  12. @Pedro Czy jest możliwa statyczna analiza na dynamicznie typowanym języku? Nie jestem specem w tym temacie, ale jakby jedno drugiemu przeczy. Samo stwierdzenie, że typ A przypisuję do B nie koniecznie musi być błędem.

    OdpowiedzUsuń
  13. @Łukasz : Jak najbardziej gdyż statyczna analiza dotyczy tego że wykonujesz je na kodzie który się nie wykonuje. a dynamiczna analiza wykonywana jest na działającym programie. Więc to czy język jest dynamicznie typowany czy statycznie może tylko ułatwić pewne rzeczy.

    W przypadku grails sprawa o tyle się upraszcza że ponieważ jest to na końcu defakto java to możesz na *.class grailsowych uruchomić wspomnianego findbugs.

    OdpowiedzUsuń
  14. Z tym findbugiem na plikach *.class to bym był ostrożny - Groovy robi niezłą sieczkę z baytcode'u :D
    Chodź ciekawe co by pokazał?!?

    OdpowiedzUsuń
  15. Łukasz, co oznacza "robi sieczkę z bajtkodu"? To tylko tyle, albo aż tyle, ile pozwala specyfikacja JVM. O sieczce może być mowa, pewnie podobnie jak z moimi aplikacjami, więc akurat Groovy niewiele śmieci :)

    OdpowiedzUsuń
  16. @Jacek spróbuj zdekompilować klasę napisaną w Groovym

    OdpowiedzUsuń
  17. @Łukasz, prosisz i masz (w postaci filmiku na YouTube - W odpowiedzi na sugestię Łukasza - dekompilacja klasy w Groovy). Wciąż nie rozumiem, do czego zmierzasz. Bajtkod to bajtkod.

    OdpowiedzUsuń
  18. @Łukasz
    Zdekompilować czy raczej zamienić na odpowiednik javowy?

    OdpowiedzUsuń
  19. @Jacek rozbrajasz mnie ;-) Jak nic musisz zmienić pracę albo zamiast pisać bloga zacząć pisać aplikacje :D

    Ciekawe jaki to skomplikowany kod może zostać wygenerowany z println :D:D:D

    Może faktycznie byłem nieprecyzyjny - chodziło mi o skompilowanie klasy do bytecode'u, następnie jego dokompilację za pomocą np. jad do kodu źródłowego.

    Domain klas, która miała cztery pola i nic więcej urosła do 11 kB, mały przykład kodu:

    public Book()
    {
    CallSite acallsite[] = $getCallSiteArray();
    metaClass = $getStaticMetaClass();
    metaClass;
    (MetaClass)ScriptBytecodeAdapter.castToType(metaClass, $get$$class$groovy$lang$MetaClass());
    this;
    JVM INSTR swap ;
    metaClass;
    JVM INSTR pop ;
    }

    Ktoś powie, że to nie argument, ale analiza takiego kodu debugerem lub profilerem może być ciekawa ;D

    OdpowiedzUsuń
  20. @Jacek : Robić sieczkę znaczy na przykładzie
    Test.java i Test2.groovy wypisuje Ala. Nie oszukując na {} mamy
    cat Test.java | wc -l
    5
    cat Test2.groovy | wc -l
    1
    ale
    javap -c Test | wc -l
    17
    javap -c Test2 | wc -l
    292

    Exceptiony też ładne nie są :)

    OdpowiedzUsuń
  21. @Łukasz : Findbugs śmiga aż miło (sprawdziłem) oczywiście trzeba dodać sporo bibliotek bo inaczej otrzymamy wiele komunikatów
    The following classes needed for analysis were missing:
    groovy.lang.Script
    groovy.lang.MetaClass itd

    Również więcej bajtkodu to więcej pracy oraz mam takie przeczucie że w przypadku używania wtyczek i innych "zaawansowanych" rzeczy to findbugs zgłosi problem do "native" kodu, a to już może być irytujące :)

    Test na grails app-create + grails war już wskazuje na 1 errorek (bad practice)

    BTW: komentowanie u Jacka jest ciężkie co chwila muszę zmieniać messejdży na komunikaty itd, ale errorka sobie zostawiłem :)

    OdpowiedzUsuń
  22. Brak statycznej typizacji jest błędem języka tak samo jak brak dynamicznej typizacji. W tym przypadku za równo Java jak i Groovy są wybrakowanymi językami. Z biegiem lat będzie to bardziej widoczne. W Groovy są metki typów - pozwalają na statyczną analizę ale powodują spowolnienie programu.

    Dynamiczna typizacja jest wymagana przez niektóre części aplikacji i w Java implementuje się to na różne dziwne sposoby. Metaprogramownie w bardzo ograniczonym zakresie implementuje się dzięki dynamic proxy (czyli Spring, Hibernate inne kontenery oraz AspectJ w wersji bez ruszania bytecodu).

    Tylko w Java system typów jest po prostu marny. Jest słabo typowana o i ma wiele nielogicznych konstrukcji, które pewnie wynikają z wymogów wydajnościowych. Np. single dispatch (przesłanianie metod)...

    Osobiście preferuje statyczną typizację, jednak Groovy też czasem używam. Jeśli mówimy o dużych aplikacjach to Groovy łatwiej wdrożyć niż Scala, bo jest łatwiejszy w nauce i mimo wszystko wprowadza (przynajmniej wymaga poznania) mniejszej liczby nowych koncepcji. Jest za to potężnym językiem pozwalającym na bardzo dużą produktywność. Ps. w Idea jest wsparcie dla wyszukiwania błędów w Groovy udające statyczną typizację.

    Zachwyt nad dynamiczną typizacją zwykle jest nadmiarowy, ponieważ większość fajnych elementów takich języków jak Groovy można zrealizować w porządnym statycznie typowanym języku (Scala nim nie jest niestety ale dobrze, że pokazała co jest możliwe). Nie można zrealizować metaprogramowania bez dynamizmu, ale wystarczyła by dodatkowa metka, typ lub operator i mielibyśmy dynamiczne programowanie w statycznie typowanym języku.

    Ciekawy artykuł:
    http://groovy.dzone.com/articles/groovy-and-static-compilation

    Ostatnio ogranicza się system typów do statycznych w rozumieniu podobny do C++ i "dynamicznych". Jest więcej opcji. W Ocaml mamy statyczną kaczo-typizację (zgodność typów zależy od dostępnych metod a nie po czym dziedziczą).

    Parę języków z Eclipse Modeling Project, jest statycznie typowanych z rozszerzalnym systemem typów. Dzięki temu można używać jednego statycznie typowanego języka do operacji nad obiektami Java, xml i tekstowym plikiem konfiguracyjnym. W tym samym czasie można korzystać z wartości z jednego źródła w drugim. Typy w takim języku określone są odpowiednio przez klasy Java, XML Schema i gramatykę języka konfiguracyjnego. Jeśli chcemy dynamiczną typizację to można taki system typów napisać i podpiąć.

    C# 4 jest za równo statycznie jak i dynamicznie typowany (może niezbyt fajnie ale jest), a język Java staje się przestarzały.

    OdpowiedzUsuń
  23. Ciekawa dyskusja z tym dynamicznym/statycznym typowaniem, chciałem tylko zauwazyc ze to programista powinien znac kod który tworzy a nie polegać na magicznych toolsach ktore wszystko robią za niego ... nie lubie generacji programistów - klikaczy, którzy nie potrafią sobie poradzic bez tych wszystkich wynalazków. Osobiscie wykorzystuje poza Javą i Scalą równiez (J)Ruby on Rails i Django i do pracy z nimi uzywam tylko i wylacznie TextMate - edytora nie IDE. Zauwazylem ze moja wiedza (znajomosc jezyka, api itd) znacznie wzrosla odkad przestalem polegac na IDE i statycznym typowaniu. Prawda jest taka ze zeby wykorzystywac dynamiczne typowanie trzeba byc doswiadczonym programistą, swiadomym mozliowsci jezyka. Ja osobiscie nie jestem fanem Groovy bo uwazam go za clona Rubego zrobionego na siłe dla tych wszystkich dla których nauczenie się skladni rubego bylo dramatem. Mimo wszystko należy docenic dynamiczne typowanie jako ceche która zwieksza elastyczność kodu i jego możliwości. Wystarczy wziasc za przyklad jezyk Python ktory nawet "dobrej" hermetyzacji nie ma, co nie przeszkadza programistom tworzyć swietne aplikacje. To nie jezyk jest wazny, to nie technologia ... tylko umiejestności osoby ktory sie nimi posługuje. Żadne narzędzie nie zastąpi np. 2 letniego doświadczenia.

    OdpowiedzUsuń
  24. @Andrzej, nie mógłbym ująć tego lepiej. Super, że spisałeś to w jednym miejscu :)

    OdpowiedzUsuń
  25. @Andrzej, raczej używasz TextMate bo brak dobrego IDE do python i ruby :p

    Kilka razy musiałem dopisać coś, lub pracować nad aplikacją pisaną kilka lat przez kilka-kilkadziesiąt osób. Nie miałem co liczyć na dokumentacje. W takiej sytuacji porządne narzędzie potrafiące analizować strukturę programu, lub zwykłe podpowiadanie metod oznaczało wymierne oszczędności czasu. Tym bardziej było potrzebne wsparcie wyspecjalizowanych narzędzi im więcej słabo-typowanych elementów w aplikacji (w szczególności wszystko co zwraca typ w zależności od podanego stringa, konfiguracja xml itd.).

    Tak samo gdy uczę się dowolnej technologii wolę mieć pod ręką CTRL+click, CTRL+H i zwykłe podpowiadanie metod bo to znacznie ułatwia naukę dowolnej technologii. Można o czymś czytać, a można kliknąć i zobaczyć źródła, przeglądnąć klasy. Można grzebać w XML, a można też zobaczyć to samo w postaci czytelnego grafu. Nie trzeba też pamiętać nieistotnych szczegółów.

    Narzędzia są tak dobre jak nasza zdolność ich stosowania.

    Groovy jest prawdopodobnie jedynym dość znanym językiem, którego celem jest ścisła współpraca z Java, w tym częściowa zgodność składniowa. Jython i JRuby to klony, może szybsze od orginałów ale są nie naturalnym tworem na JVM, do którego nie pasują.

    OdpowiedzUsuń
  26. Ten komentarz został usunięty przez autora.

    OdpowiedzUsuń
  27. "@Andrzej, raczej używasz TextMate bo brak dobrego IDE do python i ruby :p"

    @Krzysiek - mylisz się, są co najmniej 3 świetne IDE do Railsow (do Django tez jest pare):

    RubyMine / InteliJ IDEA
    Netbeans
    Aptana

    Wszystkie mają doskonałą integracje z frameworkiem Ruby on Rails mimo to korzystam z TextMate, dziwne co ? :D

    OdpowiedzUsuń
  28. Ehhh widze, ze ostra dyskusja w tym poscie :D

    Jako że mialem "przyjemnosc" pisac kilka aplikacji w Grails dodam cos od siebie :)

    Co do statycznego typowania czy tez jego braku to fakt - statyczne pomaga przy kodowaniu i pozwala faktycznie wychwycic bledy, brak statycznego typowania nie jest moim zdaniem zly ALE wymaga wiecej od programistow, nie dlatego ze sa oni lepsi czy cos tylko tak jak juz to zostalo napisane kompilator nie sprawdzi tych bledow ktore moglby sprawdzic przy statycznym typowaniu stad w wiekszym stopniu zalecane jest pisanie testow jednostkowych.

    Co do samych Grails to przyznam, ze na poczatku bylem podniecony(!) tym wynalazkiem ALE w chwili obecnej (po napisaniu wspomnianych projektow) wydaje mi sie, ze jest to framework z dosc spora iloscia bledow i momentami znacznie utrudniajacy zycie programisty (tak wiem to brzmi dziwnie)!
    Mam nadzieje, ze kolejne wydanie Grails bedzie lepsze od poprzedniego i ze bede mogl zmienic swoje zdanie :)

    Pozdrawiam,
    Radek

    OdpowiedzUsuń
  29. @Andrzej,
    Skoro ich nie używasz to nie są świetne.

    OdpowiedzUsuń
  30. Ps.

    http://enfranchisedmind.com/blog/posts/useful-things-about-static-typing/

    OdpowiedzUsuń