29 listopada 2010

Po wykładzie na PWSZ w Tarnowie

14 komentarzy
O planach związanych z wykładem pisałem w poprzednim wpisie - Wykład akademicki na PWSZ w Tarnowie - 29.11 od 9:30 do 18:00 i jak to w życiu bywa - plany swoje, a życie swoje.

Mając niemałe obawy o zakres merytoryczny wykładu, postanowiłem przelecieć większość z tego, co nazwałbym interesującym wycinkiem mojej wiedzy technicznej, aby choć na moment móc podzielić się czymś nowym z uczestnikami. Sądziłem, że uczestnicy większość tematów mają już za sobą, więc pojawiły się produkty IBM, o których, jeśli słyszano, to niewiele praktycznie i choć one gwarantowały mi możliwość przekazania czegoś niezbadanego. Po ostatnich szkoleniach z IBM WebSphere BPM z programowania i administracji nie miałem złudzeń, że w ostateczności wejdę na niskopoziomowe "rozbieranie" trzewi WPS V7 czy WAS V8. Sądziłem, że coś w końcu będzie wartościowe, aby spędzić kilka chwil i wziąć udział w wykładzie.

Do ostatniej chwili nie byłem pewien, czy dobrze dopasowałem tematykę. Czym bliżej wystąpienia, tym nachodziła mnie większa ochota, aby w niej pomajstrować. Wziąłem kilka książek, aby tam znaleźć coś unikatowego, a jednocześnie wartościowego, zabrałem się za lekturę podręczników, itp. Zacząłem odczuwać tremę przed niewstrzeleniem się w oczekiwania (które mogły być podkręcone moimi wycieczkami w różne strony rozwiązań javowych).

Zaplanowałem całkiem pokaźny bagaż tematyczny (vide poprzedni wpis z harmonogramem) i wszystko miało odbyć się bez nawet najdrobniejszego slajdu, aby ostatecznie okazać się, że z grupy około 50 osób niewiele ponad 3 osoby miały styczność z Javą (!) To było chyba najbardziej dla mnie szokujące. Ja tu zmagałem się z JEE6 i poziomy wyżej, przy SCA i BPEL, a okazało się, że należało zacząć od samego początku - samego poznawania języka Java. Trafiłem do mekki programistów C!

Jako, że przygotowany byłem na wprowadzenie do dostępu do bazy danych, przez JDBC, Hibernate, Spring Framework, Hibernate+Spring Framework, JPA i EJB, w zasadzie byłem gotowy zacząć pierwsze kilka kwadransów na wprowadzenie do Javy - bez wycieczek w programowanie OO. Pozostałem przy prostych konstrukcjach typu wyświetl na ekran, pobierz z ekranu i na tym się skończyło wprowadzenie.

Zabrałem się za dostęp do bazy danych. MySQL sprawowało się znakomicie, a NetBeans IDE (wersja rozwojowa z dnia poprzedniego) całkiem sprawnie uwijała się przy składaniu kolejnych części aplikacji. Tutaj i Java Tutorial się przydał, aby pokazać, w jaki sposób można przejść podobną ścieżkę, którą właśnie przechodziliśmy (gdyby komuś przyszło do głowy odtworzyć nasze wspólne poczyniania samodzielnie). Od czasu do czasu NetBeans IDE czkał zamrażając się na dobre kilkadziesiąt sekund, co złożyłem na braku dostępu do Sieci i jego młodzieńczego wieku (w końcu to wersja rozwojowa). Na moment przełączyłem się do Eclipse IDE, ale i jemy przypomniało się, aby zaktualizować/sprawdzić coś w Sieci i zamarzł. Wróciłem do NetBeans IDE.

Na zakończenie pierwszego bloku wykładów pokazałem coś, co określiłbym - impress me. Skąd wzięło się to cudo? Chcąc dopasować się do oczekiwań uczestników, zapytałem, co jeszcze mógłbym im pokazać i padło "Zaimponuj nam czymś w Javie, co sprawiłoby, że zechcielibyśmy się nią zająć". Od razu zabrałem się za...Clojure.

Pewnie pomyślisz sobie, zwłaszcza jeśli znasz mój poziom znajomości tego języka, że to był najgorszy z możliwych wyborów. Co to, to nie. Zdecydowanie NIE. Ja wręcz uważam, że właśnie tym najbardziej ująłem ich za serce i przy tym właśnie temacie miałem wrażenie zdobyłem ich największą uwagę. Takie odniosłem wrażenie i jeśli jakikolwiek temat miał swoje komentarze, to Clojure był zdecydowanym liderem. Dlaczego? Kwintesencją dobrej prezentacji jest dopasowanie przykładu do tematu. I tak właśnie było z Clojure.

Podczas sesji z Clojure pokazałem, jak interaktywie tworzyć aplikację okienkową, gdzie rozpoczynam od "gołej" aplikacji na bazie JFrame i dodaję kolejne elementy graficzne. Kiedy pierwszy raz wpadłem na ten pomysł, wiedziałem, że to będzie cudo. Na dole miałem terminal z Clojure REPL, na górze właśnie otworzone okienko przyszłej aplikacji okienkowej, a pod nimi Eclipse z odtwarzanym skryptem, w którym widać było wpisywane linie kodu w Clojure. Zamierzam, to nagrać w postaci skrinkastu, więc chwila i sam przekonasz się, o czym się tutaj pisze.

Clojure nie jest tutaj jakimś specjalnym czymś, co sprawiłoby, że jest to możliwe. Po prostu, jako język skryptowy - podobnie jak Groovy, JRuby, Rhino, Scala, Jython - daje możliwość nauki API przez wprowadzanie kolejnych wywołań w czymś ala Clojure REPL i natychmiastowego otrzymywania rezultatów z ich uruchomienia. Możnaby to przyrównać do środowiska ciągłej nauki API. Bajka!

Po przerwie, przeszliśmy przez Hibernate, Spring Framework i tworzenie aplikacji z servletami (obsługa formularza) z niewielkim EJB uruchamianym w ramach aplikacji webowej (nowość JEE6). W zasadzie 7 osobom udało się wytrwać do 18:00, kiedy to punktualnie zakończyłem wykład.

Bardzo pomocny okazał się stoper firmy Apimac, który odmierzał równe 40-tominutówki i późniejsze 10-ciominutowe przerwy. Super rozwiązanie, aby zagwarantować pewność utrzymania czasu przez prowadzącego. Polecam!

Czego mi brakowało podczas tego wykładu, to większego udziału publiczności. Znalazło się kilku bardziej aktywnych, ale ogólnie panowała cisza i trudno było zorientować się, czy temat ciekawił, czy warto byłoby poruszyć inne aspekty i w ogóle sprawić, aby spędzony czas był wartościowy merytorycznie. Nieskromnie powiem, że bardzo ucieszyła mnie moja lekkość w zmianie tematu, tempa i dopasowanie do poziomu, ale wolałbym bardziej skrupulatne zajęcie się pojedynczym tematem, np. JEE6 niż przejściem od Java, Clojure, Hibernate, Spring, servlety i EJB. Trochę przypominało groch z kapustą, aczkolwiek zagwarantowało, że wykład spędziłem nie nudząc się ani na chwilę. Liczę, że uczestnicy również.

Sam Tarnów bardzo spokojny. Akurat dzisiaj spadło sporo śniegu, więc wszystko zasypane, ale i tak udało mi się dostrzec tlące się piękno tego miejsca. Po 18:00 w zasadzie zero otwartych sklepów i niepokojąca cisza na ulicy. Może poza Rynkiem jest inaczej?! Ach, zastanawiam się, dlaczego zegar na Ratuszu wybija połówki, kwadrans przed pełną i pełną godzinę?

p.s. Wykład prowadzony był w ramach programu Unii Europejskiej wspierającej wymianę doświadczeń między praktykami i firmy a uczelniami, z korzyścią dla nowej kadry informatycznej - studentów. Pewnie i na Twojej uczelni jest to możliwe. Wystarczy zapytać. Resztą się zajmę. Pisz na priv z prośbą o szczegóły. Na prawdę warto.

27 listopada 2010

Wykład akademicki na PWSZ w Tarnowie - 29.11 od 9:30 do 18:00

5 komentarzy
W nadchodzący poniedziałek, 29.11 będę na Wydziale Informatyki Państwowej Wyższej Szkoły Zawodowej (PWSZ) w Tarnowie (ul. Eljasza Goldhammera) u Tomasza Potempy i jego studentów, z którym zorganizowaliśmy mój wykład dotyczący tematu Java i okolice. Głównymi odbiorcami mają być studenci 4 roku, którzy kończą semestr z końcem grudnia, aby w styczniu skupić się na pisaniu pracy inżynierskiej.

Jak to ze mną bywa przy tego typu otwartych tematach, pomysłów mam wiele i byłbym rad, o kilka wskazówek pod kątem możliwości czasowych i znaczenia rynkowego poszczególnych tematów. Celem nie jest przekazanie pełnego obrazu danego rozwiązania, ale raczej naszkicowanie możliwości, aby wybrać do dalszego rozpoznania to, co może być interesujące.

Mam do dyspozycji 2 bloki 5-godzinne (w sensie lekcyjnym nie zegarowym, czyli 45 minut). Można założyć, że w każdym bloku będzie to samo, ale to zależy od ogólnego zainteresowania uczestników oraz mojego przekonania o sensowności dalszego brnięcia w temat. Tym samym nie ma gwarancji, że drugi blok będzie odpowiadał merytorycznie pierwszemu.

Zaczynam o godzinie 9:30, aby zakończyć o 18:00 z 1-godzinną przerwą obiadową w okolicach 13:15. Okazuje się, że będzie okazja spotkać się z Tomkiem Łabuzem, którego można było poznać podczas konferencji Javarsovia 2010, podczas której prezentował temat "AOP, ThreadLocal i JPA".

Planuję przeprowadzić autorski cykl tematyczny, którego mottem byłoby "Od prostoty do większej prostoty, tj. w każdym kroku ukrywamy złożoność problemu". Nie planuję prezentować slajdów, a jedynie siedzieć przed komputerem, prezentując budowanie aplikacji i machając rekoma ze wstawkami krasomówczymi.

Konspekt

Środowiska programistyczne i uruchomieniowe, darmowe i komercyjne:
  • NetBeans IDE i Eclipse IDE
  • IBM Rational Application Developer 8 i IBM WebSphere Integration Developer 7
  • GlassFish i IBM WebSphere Application Server 8 
Klient bazodanowy - tradycyjne podłączenie do bazy danych z użyciem JDBC
  • Apache Derby (wbudowane)
  • MySQL
Hibernate - warstwa pośrednia między baza danych a aplikacja
  • ORM - zapytania bliższe programiście nie adminowi bazy danych
Hibernate + Spring Framework
  • zniesienie konieczności zarządzania bytami Hibernate
  • środowisko IoC/DI
Apache Maven - zarządzanie zależnościami projektowymi
  • zniesienie konieczności dbania o zależności poza ich deklarację
  • tworzenie projektu od zera
    • z linii poleceń
    • z IDE (NetBeans IDE)
Leiningen - Maven w Clojure
  • bez XML z językiem Clojure (wrócimy do niego niebawem)
GlassFish (w NetBeans IDE) i WAS 8 - serwer aplikacyjny JEE6 (z RAD8):
  • dostęp do bazy danych (zarządzanie transakcjami)
    • JPA
    • EJB31
  • servlet - obsługa HTTP
  • JSF - budowanie widoku
    • facelets
  • CDI
EJB 3.1
  • Apache OpenEJB
  • Serwer aplikacyjny - GlassFish i WAS8
OSGi - modularność
  • podział projektu na moduły w Apache Maven był podziałem funkcjonalnym (jak OSGi)
  • samodzielna aplikacja
Clojure - język funkcyjny
  • dynamiczne tworzenie aplikacji okienkowej
Service Component Architecture (SCA) i procesy BPEL (WID/WPS)
  • odseparowanie kontraktu (interfejsu) od implementacji
  • odseparowanie szczegółów komunikacyjnych od implementacji
Wyjeżdżam z Tarnowa dopiero we wtorek, więc jeśli ktoś reflektuje na spotkanie, proszę o kontakt.

20 listopada 2010

72. spotkanie Warszawa JUG - Jacek Laskowski z "Clojure praktyczniej: REPL, Eclipse CCW, Eclipse Mylyn, monady i defrecord"

0 komentarzy
Warszawska Grupa Użytkowników Technologii Java (Warszawa JUG)Warszawska Grupa Użytkowników Javy (Warszawa JUG) zaprasza na 72. spotkanie, które odbędzie się w najbliższy wtorek, 23. listopada o godzinie 18:00 w sali 5440 Wydziału MIM UW przy ul. Banacha 2 w Warszawie.

Temat: Clojure praktyczniej: REPL, Eclipse CCW, Eclipse Mylyn, monady i defrecord
Prelegent: Jacek Laskowski

Kontynuacja relacji z mojej nauki języka funkcyjnego na wirtualnej maszynie Javy - Clojure. Tym razem przedstawię bardziej praktyczną część mojej nauki Clojure, od strony środowiska, w którym go poznaję z pewnymi elementami języka. Zaprezentuję Clojure REPL, wsparcie narzędziowe oferowane przez wtyczki Eclipse: CounterClockWise (CCW) i Mylyn oraz wstęp do monad i defrecord. Sądzę, że dzięki tej wiedzy będzie łatwiej rozpoczać samodzielną naukę Clojure.

Jacek Laskowski jest założycielem i liderem grupy warszawskich użytkowników Javy - Warszawa JUG. Prowadzi bloga Notatnik Projektanta Java EE, w którym przedstawia swoje użycie Javy i okolic. Zawodowo w IBM jako specjalista produktów z rodziny WebSphere, głównie WebSphere BPM z flagowymi produktami: IBM WebSphere Dynamic Process Edition i IBM WebSphere Lombardi Edition. Nadaje na falach twittera jako @jaceklaskowski.

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

Wstęp wolny

Zapraszam w imieniu swoim i grupy Warszawa JUG!

18 listopada 2010

Praca inżynierska z JSF2? Może jednak CDI i OSGi?

4 komentarzy
Kilkakrotnie pytano mnie o tematy prac inżynierskich i magisterskich, a wtedy zaczyna się główkowanie, który byłby tym jedynym, interesującym. Kiedy wyszła Java EE 5 byłem zachwycony zmianami, podobnie z JEE6. Było też zainteresowanie OSGi i okolicami, teraz programowanie funkcyjne z Clojure, a w odwodzie kilka innych, mniej lub bardziej ciekawych zagadnień. Nawet dzisiaj zostałem poproszony o wyznaczenie tematów do przedstawienia studentom w ramach praktyk studenckich w IBM i w mgnieniu oka miałem 10 sztywno określonych i jeden otwarty, który rozpoczynał się od "Rozpoznanie wybranej funkcji* produktu z rodziny IBM WebSphere BPM". Współpraca ze studentami to niezwykle ciekawy i produktywny sposób na poznawanie nowego (człowieka i jego sposobu myślenia oraz samego tematu). Wszyscy zadowoleni.

Postanowiłem rzucić temat wyszukania czegoś ciekawego na bloga licząc, że ktoś ma pomysł w zakresie JavaServer Faces (JSF) 2.0, a boryka się z problemem braku czasu na jego dogłębne rozpoznanie w postaci pracy licencjackiej (to jakby nie patrzeć rok ślęczenia nad tematem!).

Autor ostatniej prośby napisał:

Czy istnieje możliwość nawiązania współpracy w zakresie mojej pracy inżynierskiej, naturalnie związanej z korporacyjną Javą. Chciałbym zrealizować temat nie tylko wartościowy merytorycznie ale i również interesujący z punktu widzenia programisty, wolałbym uniknąć pracy odtwórczej i skupić się na tym co mógłbym poprzez swoją pracę dyplomową wnieść od siebie. Jestem już po wstępnej rozmowie z moim promotorem, z którym rozważaliśmy możliwość podjęcia tematu związanego mniej lub bardziej z JSF 2.0. Wiem, że jesteś otwarty na różnorodne propozycje, dlatego po cichu liczę na email od Ciebie przesiąknięty entuzjazmem, który mnie nie opuszcza nawet na krok podczas rozważań nad tematem mojej pracy.

Na moją odpowiedź, raczej w tonie ostrożnej aprobaty, otrzymałem taką:

Dzięki za zainteresowanie moją propozycją, tak jak już wcześniej wspomniałem chciałbym poprzez swoją pracę dyplomową wnieść coś od siebie. Wykorzystanie JSF2 do zbudowania przykładowej aplikacji webowej jest ostatecznym rozwiązaniem, którego nawet nie chcę brać pod uwagę. Idealnym rozwiązaniem byłby temat oryginalny oraz interesujący.

W kwestii tematu właśnie liczyłbym na Twoją pomoc, z pewnością są zagadnienia związane z JSF2, którymi zainteresowany jesteś najbardziej. Wiedzę w tej dziedzinie masz nieporównywalnie większą niż moja, stąd zapewne mógłbyś zaproponować kilka interesujących pomysłów. Może istnieje jakieś komercyjne narzędzie (lub jego część), które czeka na swoją ogólnodostępną implementację? A może masz zupełnie inny pomysł na temat pracy?


I tutaj pojawiła się moja odpowiedź, już z wstępnym szkicem zakresu technologicznego pracy:

JSF2 jest ciekawe, ale coś mi mówi, że wiele tu już zrobiono i ciekawym mogłoby być użycie innej technologii tworzenia UI niż facelets czy JSP. Przyjrzałbym się jednak bardziej użyciu CDI w JSF i co do tej pory zrobiono. CDI jako rozwiązanie javowe weszło dopiero w JEE6, więc jest bardzo młode i pewnie wiele tutaj do zrobienia. Gdybym miał szukać ciekawego tematu właśnie koło CDI kręciłbym się, może w połączeniu z OSGi?! Właśnie CDI + OSGi wydaje się być nietrywialnym tematem dotykającym dwa rozwiązania. To byłoby cudo techniczne!

Uważacie, że JSF2, CDI i OSGi mogłoby być "produktywnym" stosem technologicznym? Co mógł(a)byś Ty zaproponować delikwentowi? Mnie zawsze intrygowało, czy dałoby się tak użyć JSF, aby zbudować aplikację desktopową? W końcu JSF dotyka warstwy widoku i aplikacje webowe są jedynie/aż implementacją referencyjną demonstrującą oferowane możliwości (albo ich brak) budowania niebagatelnego interfejsu użytkownika. Gdyby relacjonować JSF2, czy byłoby cokolwiek, co stanowiłoby dla Ciebie szczególnie ciekawe zagadnienie? Wszelkie propozycje będą uważnie rozpatrzone, a upublicznione mają niemałe szanse na realizację. Dla mnie będzie to stanowiło magnes do powrotu do Java EE 6, które zeszło na plan drugi po pojawieniu się Clojure, dla Ciebie zrealizowanie pomysłu cudzymi rękoma, a pytającemu zapewnią ciekawe spędzenie czasu przy pracy inżynierskiej. Wszyscy są do przodu!

[*] Dowiedziałem się dzisiaj, że nie ma liczby mnogiej od "funkcjonalność", a można mówić jedynie o funkcjach produktu (!)

10 listopada 2010

Monady maybe odsłona kolejna - rozwiązanie problemu nr 1

5 komentarzy
Logo ClojurePamiętamy 2 problemy z wpisu "O warsjawie i monadach w Clojure - nauka wspólnie jako sposób własnego rozwoju"? Daniel zaproponował rozwiązanie w Clojure (nota bene, tam dowiedziałem się o możliwości nazywania bytów w Clojure tak nieszablonowo jak "kraj->waluta"!), a Grzesiek w Scali. Grzesiek postawił kolejny problem: "Nie mam pojecia jaki zwiazek maja zaproponowane przez Ciebie problemy z monadami", na który postaram się dać odpowiedź w tym wpisie.

Rozwiązanie do problemu 1. polega na wychwyceniu sytuacji, w której poszukiwana wartość nie istnieje, której wystąpienie powinno zatrzymać kolejne obliczenia. Pozwoliłem sobie na użycie terminu obliczenie jako zastępstwa dla "funkcja", aby przywyczajać do pewnej abstrakcji, którą wprowadzają monady, z którymi są one nierozerwalnie skojarzone.

W Javie obsłużylibyśmy taką sytuację przez zastosowanie "wzorca"
if (nieZnaleziono) return null;
zanim wykona się kolejne obliczenie. To nakłada pewną dyscyplinę na programistę, aby pamiętał o takiej konstrukcji lub innym, właściwym obsłużeniu oraz (co bardziej istotne) niepotrzebnie zaciemnia treść metody. Są inne, ładniejsze rozwiązania i liczę na ich prezentacje w postaci komentarzy do tego wpisu (które wykorzystam do kolejnych odsłon "monadycznych").

Rozwiązanie Daniela, jakkolwiek bardzo twórcze i wiele się można z niego nauczyć, jest jednak obarczone problemem ignorowania sytuacji wyjątkowej, w której nieistnienie elementu w zbiorze nie powoduje zatrzymania kolejnych obliczeń, a więc w którymś momencie może doprowadzić do NPE (!) Można się o tym przekonać modyfikując nieznacznie zaproponowane rozwiązanie.
user=> (defn printlnX
  [v]
  (do
    (println "Wykonano z:" v) ; wyświetl wartość
    v                         ; zwróć ją
    ))
user=> (defn pracownik->waluta [p] (-> p printlnX pracownik->departament printlnX departament->kraj printlnX kraj->waluta printlnX))
#'user/pracownik->waluta
user=> (pracownik->waluta "Daniel")
Wykonano z: Daniel
Wykonano z: nil
Wykonano z: nil
Wykonano z: nil
nil
Co oznacza ni mniej ni więcej, że każde z kolejnych obliczeń było wykonane.

A co powiecie o takim rozwiązaniu?
user=> (defn pracownik->waluta
  [p]
  (domonad maybe-m
    [dept (pracownik->departament p)
     kraj (departament->kraj dept)
     waluta (kraj->waluta kraj)]
    waluta))
Tym razem opieram się na wykorzystaniu monady maybe, której działanie można streścić tak: "Jeśli dowolne obliczenie w serii obliczeń zwróci nil/null/wartość nieporządaną, kończymy". Sprawdźmy (musimy wcześniej dodać do niej "magiczne" printlnX).
user=> (defn pracownik->waluta
  [p]
  (domonad maybe-m
    [_ (printlnX p)
     dept (pracownik->departament p)
     _ (printlnX dept)
     kraj (departament->kraj dept)
     _ (printlnX kraj)
     waluta (kraj->waluta kraj)]
    waluta))
user=> (pracownik->waluta "Daniel")
Wykonano z: Daniel
nil
Konwencją w Clojure jest oznaczenie wartości przez podkreślnik "_", jeśli nie interesuje nas.

Czy teraz widać różnicę? Dzięki monadzie maybe kolejne obliczenia nie są wyliczane, co często nazywa się "szybkim przerwaniem" - jeśli już wystąpi błąd, to nie ma sensu wykonywać kolejnych kroków w ciągu obliczeń. Podobnie działa LinQ.

Na zakończenie jeszcze jeden przykład, który może uzmysłowić znaczenie monady maybe i transformat monadycznych, czyli możliwości składania lub modyfikowania monad.

Załóżmy, że nasza aplikacja zawiera serię ekranów. Jeśli użytkownik wciśnie "Zatrzymaj" albo "Anuluj", kolejne - z oczywistych względów - nie powinny być wyświetlone. Dobrze byłoby móc zająć się jedynie wyświetlaną treścią bez konieczności dbania o detale obsługi zdarzenia zatrzymaj czy anuluj. To pozostawiamy pewnemu, bardziej generycznemu rozwiązaniu, które co najwyżej konfigurujemy dopasowując do naszych potrzeb. I tutaj właśnie widzę zastosowanie dla monady maybe. Tym razem wartością szczególną będzie 1.
user=> (def screen-maybe-m (maybe-t maybe-m 1))

user=> (import 'javax.swing.JOptionPane)

user=> (defn showConfirmDialog
  [step]
  (JOptionPane/showConfirmDialog nil (str "Step" step ": Continue?") "Monads" JOptionPane/YES_NO_OPTION))
  
user=> (defn screen1
  []
  (showConfirmDialog 1))

user=> (defn screen2
  []
  (showConfirmDialog 2))

user=> (defn screen3
  []
  (showConfirmDialog 3))

user=> (domonad screen-maybe-m
  [_ (screen1)
   _ (screen2)
   _ (screen3)]
    "Wykonano całość")
Tylko, jeśli użytkownik zaakceptuje wszystkie z wyświetlonych ekranów, nastąpi wyświetlenie "Wykonano całość". Sprawdzenie prawdziwości tego stwierdzenia pozostawiam Tobie.

08 listopada 2010

Clojure, wyrażenia regularne i ćwiartowanie

1 komentarzy
Logo ClojureIleż to razy obiecywałem sobie, że przysiądę nad wyrażeniami regularnymi. Pamiętam, jak proste było ich użycie w Groovy, a teraz, kiedy spędzam część mojego czasu z Clojure, nie jest inaczej - ponownie łatwizna. Zgoda, nie jest łatwo, jeśli nie wiadomo, jak się je konstruuje, ale jest prościej niż w Javie (co miało być potworzone, już jest gotowe do użycia). Dzisiaj miałem 2 bliższe spotkania z wyrażeniami regularnymi i oba były olśniewające.

Potrzebowałem odszukać definicji fn* w Clojure. Wszedłem na kanał #clojure na IRC i w niecałą minutę, może dwie, miałem swoją odpowiedź - fn* to specjalny symbol w Clojure (zainteresowanych źródłami odsyłam do klasy clojure.lang.Compiler).

Kiedy poszukiwałem fn* z grep wiedziałem, że muszę wyłączyć specjalność gwiazdki, więc do poszukiwań użyłem grep "fn\*" src/clj/clojure/core.clj. Prościzna. Czego jednak nie wiedziałem, to że w vi gwiazdka jest również specjalna (w końcu vi to wizualny sed, a ten wyrażenia regularne traktuje podobnie jak grep). Jakież było moje zdumienie, kiedy szukając w vi ciągu znaków "fn*" skakałem początkowo po wyrazach for, software, found, i takie tam. Dopiero wtedy uzmysłowiłem sobie, że gwiazdka oznacza 0 lub więcej wystąpień i fn* pasuje do wymienionych idealnie, bo vi traktuje gwiazdkę specjalnie. Wystarczyło ponownie odszukać "fn\*".

Jakby tego było mało, chwilę później na kanale @learnclojure na twitterze, trafiłem na cudowny kawałek kodu z...wyrażeniem regularnym! Czyż to nie podwójnie olśniewające?!
(defn vectorize-date-str [ds]
  (let [[date m d y] (re-matches #"(\d{1,2})\/(\d{1,2})\/(\d{4})" ds)]
    [y m d]))

(vectorize-date-str "12/02/1975")
;=> ["1975" "12" "02]
Funkcja vectorize-date-str opiera się na dwóch użytecznych funkcjonalnościach wbudowanych w język Clojure - "ćwiartowanie"* parametrów (ang. destructuring) oraz funkcji re-matches. Obie konstrukcje dzielą parametr wejściowy, którym jest ciąg znaków reprezentujący datę w formacie mm/dd/YYYY na listę rok, miesiąc, dzień.

Przyznaję się bez bicia, że propozycja rozwiązania tego problemu z użyciem wyrażeń regularnych byłaby ostatnia w zaproponowanych, jeśli w ogóle pojawiłaby się (!) Już przekonałem się do "ćwiartowania" parametrów (więcej w Special Forms/(let [bindings* ] exprs*)), jako wstępnego przygotowania parametrów wejściowych (i swego rodzaju kontraktu między klientem funkcji, a nią samą), ale wyrażenia regularne wciąż były przeze mnie traktowane po macoszemu. Od dzisiaj koniec z tym!

[*] Propozycje tłumaczenia destructuring mile widziane. Proszę o coś bardziej wyrafinowanego niż destrukturyzacja.

06 listopada 2010

71. spotkanie Warszawa JUG - Cezary Bartoszuk z "Sztuczki w językach programowania"

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

Temat: Sztuczki w językach programowania
Prelegent: Cezary Bartoszuk

Rozwijane obecnie języki programowania pełne są sztuczek: technik, wzorców, metod lub przepisów, których przyjęło się używać do osiągnięcia konkretnego celu. Sądzę, że aby poszerzyć swoją wiedzę o programowaniu warto poznać smaki ciekawych sztuczek stosowanych w różnych językach programowania.

Pogadankę o "sztuczkach" (jak będę je nazywał ze względu na to, że są bytami bardzo różnych rodzajów) podzieliłem na trzy zasadniczo różne części:

1) Typowanie
2) Przepływ danych
3) Przepływ sterowania

W każdej z tych części w sposób dość popularnonaukowy (i w dużej mierze opierając się na intuicjach) omówię kilka sztuczek, jakie stosowane są w językach programowania. Każda sztuczka będzie miała charakter informacyjny wraz z krótkim przejrzeniem plusów i minusów danego rozwiązania.

Do worka ze sztuczkami wrzucę między innymi: funkcje i typy wyższych rzędów, kontynuacje, jedną lub dwie monady i polimorfizm w różnych smakach.

Cezary Bartoszuk jest studentem Wydziału Matematyki, Informatyki i Mechaniki, kierunku informatyka. Interesuje się programowaniem funkcyjnym, współbieżnością i clean-codem. Zawodowo programista Pythona.

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

Wstęp wolny

Zapraszam w imieniu prelegenta i grupy Warszawa JUG!

03 listopada 2010

Samodoskonalenie zwinnych zespołów

3 komentarzy
3 dni wolnego, to doskonały moment, aby się chwilę zastanowić. Można się było nawet zastanawiać, nad czym by się tu zastanowić (!) Szacunek dla szczęśliwców.

Mnie wzięło na rozmyślania o terminie samodoskonalenie w połączeniu ze zwinnym zespołem. Wciąż rozmyślam, jakich sposobów używać, aby zachęcić do większej aktywności w ramach społeczności typu Warszawa JUG. Niby jest ponad 400 członków, a ruch na grupie, jakby było nie więcej niż 50. Czyżby pozostali nie posiadali własnego zdania?! Niemożliwe.

W tym kontekście, rozmyślam, jak wyglądałby mój doskonały zespół, gdyby mi przyszło prowadzić jakiś. Czy byłby zwinny i tym samym samodoskonalił się? Jak stałby się zwinny? I kiedy mógłbym stwierdzić, że jest samodokonalający się?

W moim przekonaniu samodoskonalenie jest wpisane w kontrakt zwinnego zespołu. Po prostu, jeśli jesteś zwinny (technicznie), to musisz się ciągle rozwijać. Możnaby postawić tezę, że siła zwinności liczona jest przez ilość czasu poświęcanego na rozwój siebie i "okolicy". Od ludzi posiadających taką cechę, czym ona mocniejsza, tym bardziej emanuje na innych. Taki zespół nie czeka na prośbę podzielenia się wiedzą, ale robi to regularnie i otwarcie. Jednym z "objawów" jest m.in. posiadanie własnego bloga (przez "własny" rozumiem taki, z którym się identyfikujemy - rzeczywiście własny lub całego zespołu).

Mam nieodparte wrażenie, że powszechnie pojęcie zwinnego zespołu kojarzy się głównie z posługiwanymi się narzędziami i technikami, które określa się jako zwinne - techniki Agile. Uważam, że to tylko jeden z trybików. Zgodnie z definicją słowa na pwn.pl "zwinny" to 1. «wykonujący szybkie, zręczne ruchy», 2. «o ruchach, poruszaniu się kogoś lub czegoś: szybki i zgrabny». Dokładnie odpowiada mojemu postrzeganiu zwinnego zespołu - jest zręczny, szybki i zgrabny (wszystko w kontekście jego "wyglądu" i zachowania stricte technicznego)

W moim rozumieniu zręczność techniczna zespołu jest cechą jego przygotowania do zastosowania odpowiedniego narzędzia do problemu. Tutaj liczy się znajomość wszystkich "cudów świata" - czym więcej języków programowania, bibliotek, szkieletów, produktów, tym lepiej. Niech znajomość ich będzie pobieżna, ale wystarczająca do podjęcia decyzji o zastosowaniu jednego vs drugiego.

Szybkość zespołu jest cechą, w której sama znajomość jest poparta pewnością wyboru narzędzia i umiejętnością jego wdrożenia - implementacji. Z szybkością kojarzy mi się bardziej pewność działania (ale nie arogancja!) niż czas. Tutaj liczy się posiadanie speców od danej technologi, którzy wykazują się większą niż przeciętna znajomością tematu. Nie oznacza to jednak, że całe ich dnie wyglądają podobnie - wciąż wałkują ten sam temat, a raczej szczególniej mu się przyglądają. Powiedzmy, że ta szczególność polega na poświęceniu tematowi 20% więcej czasu.

Zgrabność zespołu jest cechą, w której umiejętnie dopasowuje się do sytuacji. "Ciągłe ćwiczenia są kluczem do sukcesu" świetnie tutaj pasuje. Ciągłe próbowanie się z nowym i ciągłe dzielenie się wiedzą, aby w końcu ciągle następował przepływ wiedzy, którą można korygować, wzbogacać i ostatecznie zastosowywać. Niech wiedzą, kto wie, abyśmy wiedzieli, że wiemy :) Łatwo wpaść w zniechęcenie, kiedy człowiek sobie uzmysławia, jak niewiele wie. Pozytywne sygnały z zewnątrz mogą być niezwykle motywujące.

Kluczem jest wiedza i chęć jej zdobywania.

To, ile czasu poświęcamy na poznawanie, zależy wyłącznie od nas samych. To, ile czasu poświęcamy na dzielenie się wiedzą, również. Zastanawiam się więc, skąd tak niewielu z nas ma na to ochotę? Poznawajmy, próbujmy, dzielmy się wynikami, spostrzeżeniami i dyskutujmy. Niech Ci, co wiedzą, wiedzą, że my nie wiemy, a Ci, którzy nie wiedzą, wręcz przeciwnie, wiedzieli, że my wiemy. W końcu musi nadejść moment, w którym komuś zacznie się wszystko składać w coś sensownego i podzieli się z innymi, oszczędzając nam wysiłku, abyśmy mogli zabrać się za kolejny problem.

W jaki sposób uczyć się? Polecam czytanie, duuuużo czytania. Kiedy skończy się czytanie, warto podzielić się swoimi przemyśleniami - zacznijmy od bloga, w postaci krótkiej notki, albo wręcz mikrobloga (ala twitter lub delicious), gdzie pojawi się choćby ślad naszej aktywności w danym obszarze. Może też być podczas 30-minutowego spotkania zespołu pod koniec tygodnia, np. w czwartek, albo wystąpienia na spotkaniu JUGowym (mamy ich ponad 10 w Polsce!) W zasadzie, niech będzie wszystko po trochu. Czym szybciej wyłożymy nasze problemy do publicznego osądu, tym szybciej uda nam się dotrzeć do rozwiązania. Ludzie z natury są życzliwi i chcą pomóc. Są jednocześnie samolubni, więc widząc, że jest gość, który przygotuje, a później zreferuje, przyjdą i zadadzą pytanie bądź dwa. W ten sposób, osoba ucząca się zdobędzie postrzeganie innych, a oni w zamian dostaną naszą relację, nasze streszczenie tematu. Obie strony będą usatysfakcjonowane. Nikt nie traci.

Podsumowując: uczmy się i innych. Starajmy się dzielić wiedzą i inspirować innych do działania, ciągłego działania. Jeśli on to robi i Ty zaczniesz, to koniec końców znajdą się wreszcie inni, którzy widząc naszej sukcesy, zechcą pójść w nasze ślady (porażki również odnotowujemy w kolumnie sukcesów, bo nic tak nie "pionuje" jak solidna dawka porażki). Któż nie chciałby osiągać celu krócej? Satysfakcja gwarantowana.

Zastanawiasz się, od czego należałoby zacząć?! Zakładasz bloga i raz w tygodniu umieszczasz podsumowanie swojej tygodniowej działalności (nie masz co pisać, powinno być odczytywane jako strata tygodnia i pora zabrać się za inne, bardziej twórcze zajęcie). Potraktuj każde z wykonywanych czynności, jako możliwość nauki. Chcą, abyś coś sprawdził, sprawdź i jeszcze dodaj coś od siebie, np. niech to kolejnym razem będzie automatycznie, albo niech będzie spisane. Pomyśl o spotkaniach zespołu, podczas których dzielicie się ostatnimi doświadczeniami - coś ala retrospekcja, czy podsumowanie iteracji, czy jak to tam się mogłoby nazywać. Chodzi o bezpośredni kontakt z zespołem. Gdzieś ostatnio przeczytałem (w wolnym tłumaczeniu) "Skoro już jesteś, bądź zauważonym". Lans jeszcze nikomu nie zaszkodził :) Tylko z umiarem.

Sądzę, że po kilku tygodniach śmiało można będzie nazwać Cię liderem zwinnego zespołu. Gratulacje!