Skip to main content

Confitura 2012 - podziękowanie i uwagi

As an exception, this article is written in Polish as it is related to my talk at Confitura 2012 conference in Warsaw. It was chosen second best talk according to attendees votes - I would like to thank for that and relate to some of the comments.

Kilka miesięcy temu miałem ogromną przyjemność poprowadzić wykład "Uwolnić się od if" podczas Confitury 2012. Frekwencja na mojej prezentacji w szacownych murach Uniwersytetu Warszawskiego oraz jej pozytywne przyjęcie były dla mnie ogromnym zaskoczeniem. Nagranie dostępne jest poniżej (oraz na Parleys ze slajdami):


Jeszcze większym zaskoczeniem były wyniki pokonferencyjnej ankiety. Jak się okazuje, w oczach uczestników, lepsza od mojej prezentacji okazała się jedynie ta prowadzona przez Sławomira Sobótkę - gratulacje dla niego za znakomity wykład i zasłużone zwycięstwo! Tak prezentuje się podium:
  1. 4,55: Ścisły przewodnik po aspektach miękkich dla ekspertów IT - Sławomir Sobótka
  2. 4,22: Uwolnić się od "if" - Tomasz Nurkiewicz
  3. 4,20: Zwinne szacowanie - Piotr Burdyło
Żeby jednak nie popaść w zbiorowy entuzjazm podzielę się z Wami komentarzami, jakie otrzymała moja prezentacja w tejże ankiecie (bez cenzury i w oryginalnej kolejności) i ustosunkuję się do tych bardziej krytycznych:

  • Trochę mało :(
  • Bardzo się zawiodłem na tym wykładzie. Przykłady były proste i oczywiste, ich refaktoryzacja również. Live coding wypadł słabo, o wiele lepsze byłyby gotowe slajdy.
Przykro mi. Celowałem raczej w podstawy, bardziej złożony i wieloetapowy refaktoring (rodem z Clean Code) byłby po prostu nudny (?) Co do kodowania na żywo - dopiero po fakcie dowiedziałem się, jak mizerny był widok na rzutnikach. Przepraszam za to, nie zdążyłem tego sprawdzić. Mam nadzieję, że to jedyny zarzut w tej materii.
  • Generalnie nic nowego. Ale prezentacja dobra
  • Jedna z lepszych prezentacji, na których byłem. Prowadzący dobrze przygotowany, ciekawe i dobrze dobrane przykłady. Dobry kandydat do dłuższej, wrsztatowej wersji wykładu.
  • plus za realne przykłady i prezentację poparta doświadczeniem
  • Prezentacja na temat, bardzo podobało mi się, że informacje w niej zawarte będą tak samo przydatne dla piszących w javie dla zastosowań biznesowych, desktopowych czy mobilnych. Śmiało mogę stwierdzić, że jest to jedna z najlepszych prezentacji na których byłem. Dobry kontakt z publicznością, ciekawe przykłady.
  • ciekawe jednak spodziewałem się stwierdzenia "nie mówię żebyście nie pisali if - piszcie gdy naprawde trzeba"
  • Niektóre momenty były przekombinowane, ale ogólnie rzecz biorąc Tomek nie zawodzi :) tak trzymać!
  • "Chyba najsensowniejsza prezentacja na ktorej bylem. Autor znajacy sie na rzeczy, mowiacy ciekawie , patrzacy krytycznie na swoj kod i zachecajacy do ruszenia glowa a nie stosowania ""najlepszych wzorcow"". Prezentacja bardzo przyjemna i ciekawa - moj numer 1"
  • Ciekawe i konkretne. Nie była to jakaś bardzo zaawansowana ale i tak ciekawa :)
  • Daję opinię 'dobrze', gdyż merytorycznie prezentacja przygotowana została dobrze i nie można się do niej przyczepić - kodowanie na żywo dopracowane, celne uwagi. Dałbym 'bardzo dobrze' ale jedna uwaga - na prezentacji poruszającej tą tematykę byłem chyba po raz 3 i nic mnie nie zaskoczyło.
  • Ciekawie opowiadał, energicznie, ale dało się go zrozumieć i nie dał się zagiąć publiczności.
  • Najciekawszy wykład, na którym byłem. Dużo konkretnych i przydatnych przykładów oraz antyprzykłady zmuszające do myślenia. Duży plus.
  • Praktycznie, przekonująco, dynamicznie.
  • Bardzo przyjemnie i żwawo :-)
  • Wg mnie najlepsza prezentacja - może nie jakaś bardzo odkrywcza, ale świetnie przeprowadzona, bez dogmatycznych wniosków.
  • Prezenter świetny - duża charyzma, swoboda wypowiadania się! Oczekiwałem czegoś więcej od treści merytorycznej. Owszem, było tu kilka fajnych pomyslów, ale oczekiwałem czegoś na temat "if" w zdecydowanie bardziej skomplikowanych przypadkach, więc merytoryznie byłem średnio kontent. Spodziewałem się klas konfiguracyjnych, klas agregujących odpowiedzialności, zoo keeperów i innych ciekawych sposobów. Z prezentacji wyszedłem jednak bardzo zadowolony - świetne widowisko.
Wygląda na to, że temat wyraźnie wymaga pogłębienia. Jeśli nie w formie prezentacji, to warsztatów - albo przynajmniej kilku wpisów na blogu. Czy mógłbym prosić autora komentarza o podesłanie materiałów/wzorców, który powinienem wziąć (nomen omen) "na warsztat"? Niektóre nazwy są dla mnie obce.
  • Krótka, zwięzła i na temat.
  • Kodowanie na żywo, trudna sprawa ale wyszło super. Bardzo dobre przygotowanie, wcinanie żarciki urozmaicały wykład
  • słabo było widać na rzutniku :), ogolnie ok
Przykro mi z tego powodu, nie zdążyłem sprawdzić widoczności przed wykładem, poprzednia prezentacja trochę się przedłużyła. Następnym razem, jeśli się uda, zwrócę na środki audiowizualne szczególną uwagę.
  • bardzo fajne przykłady, bardzo dobry sposób prowadzenia prezentacji, bardzo przydatny temat,
  • próbowałem zastosować wskazówki, ale niestety w niewielu miejscach mogły one być zastosowane (spróbuję ponownie przy refaktoringu)"
Pisz do mnie śmiało. Pomogę i za pozwoleniem podzielę się efektami refaktoringu na blogu!
  • Super !, prowadzący zna sie na rzeczy, umiał wyjść z trudnych pytań. Złapał kontakt i dyskusję. W końcu prezentacja jak dobrze kodować oby więcej takich.
  • Ciekawa, dobrze prowadzona. Sprawne kodowanie online.
  • Genialna prezentacja, trochę luźniejsza formuła. Świetne przykłady.
  • Ciekawa prezentacja, widać że Tomek do doświadczony programista z ogromną widzą. Słaba jakoś rzutników uniemożliwiała niestety dokładne przyjrzenie się przykładom. Sama prezentacja bardzo ciekawa.
  • Sporo przykladow w kodzie. Jasno, przejrzysto i na poziomie!
  • Trzeba dawać większą czcionkę na projektor
  • "Bardzo dobra prezentacja. Programowanie na żywo, przykłady z życia. Tomasz bardzo sprawnie posługuje się Intellij Idea - dla osób nie znających tego IDE część zmian w kodzie mogła być zbyt szybka."
  • Najlepsza prezentacja na tegorocznej confiturze, z tych co widziałem. Dobre tempo, dobry humor, prowadzący kompetentny, widać ze clean code to jego domena. A równoczesnie bez dogmatyzmu i wpadania w przesadę. Trochę teorii, trochę kodu, konkrety, bez lania wody, bez hype'u. Tylko życzyć aby wszystkie prezentacje na confiturze były takie.
  • jedna z niewielu prezentacji której temat pokrywał się z treścią a prowadzący wiedział co robi
  • Tomek Nurkiewicz to typ człowieka, który umie sprzedać swoją historię. Opowiadałby o sprzedaży pietruszki i też fajnie by się słuchało. Merytorycznie nie dowiedziałem się nic i trochę się zawiodłem, ale jednak czas nie uważam za stracony. Duzy plus.
  • odkrywcze pomysły i pokazanie sciezek myślenia
  • OK, choć jak dla mnie za duży nacisk na patterny.
Owszem, w końcu po coś je wymyślono. Chociaż chyba spory nacisk położyłem również na to, by ślepo ich nie stosować (?)
  • Nadrobiła trochę po prezentacji Grzegorza Balcereka
  • Najważniejsze aby zachować umiar to IMHO najlepsza porada na konferencji
  • w większości przypadków "wyważanie otwartych drzwi". Nie zostałem przekonany że brak ifów jest super
Zapraszam do dalszego komentowania, może znajdziemy jakiś kompromis? Aby programistom utrzymującym nasz kod żyło się lepiej - bo przecież o to chodzi.
  • "rewelacyjna prezentacja, choć sam temat prezentacji nie zwiastował większych rewelacji
  • dlaczego była wtedy kiedy moja i nie mogłem pójść :(
  • Sama prezentacja bardzo ciekawa, prowadzący bardzo komunikatywny tylko trochę wąski temat.
  • Profesjonalna prezentacja prowadzona przez profesjonalistę bez zbytecznych fajerwerków. Dużo ważnej i pouczającej treści.
  • Motyw z wielomianem - mistrz :D

Podsumowanie

  • Zasadniczo się podobało, dziękuję i cieszy mnie, że nie zmarnowałem godziny Waszego życia
  • Za mało/za krótko/za prosto - powiem szczerze, że z wielką chęcią poprowadziłbym warsztaty, gdzie moglibyśmy w węższym gronie podyskutować i razem pokodować. Wtedy łatwiej skupić się nad większymi przykładami
  • Mimo obecności trzech projektorów na sali, były problemy z odbiorem prezentacji, zwłaszcza podczas kodowania na żywo. Jest to dla mnie cenna nauczka na przyszłość.
Podczas mojej prezentacji [zdjęcie za zgodą fotomilo.pl]

Jeszcze raz dziękuję wszystkim za przybycie i oddane głosy. Może zobaczymy się za rok? Z całą pewnością pojawię się jako uczestnik.

Comments

  1. Jeśli miałbyś czas i chęci to może chciałbyś poprowadzić takie warsztaty na tegorocznej Warsjawie? :)

    Chłopaki szukają właśnie osób, które chciałyby coś poprowadzić w ramach tej imprezy. Więcej na http://warszawa.jug.pl/warsjawa-2012

    ReplyDelete
    Replies
    1. Zastanawiałem się nad tym, ale niestety nie dam rady być wtedy w Polsce :-(.

      Delete
  2. Nie "zwycięztwo" a zwycięstwo. Pozdrawiam

    ReplyDelete
  3. Tak sobie patrzyłem na ten przykład z datami i pomyślałem, że w scali można by było zrobić pewnie równie krótko jak Twoimi ifami, a bardziej deklaratywnie i co najważniejsze, bez ifów :-).

    import org.joda.time.DateTime
    import org.joda.time.DateTimeConstants._

    object DateConditions extends App {

    val messages = List(
    ((d: DateTime) => d.getDayOfWeek == WEDNESDAY) -> "Wed",
    ((d: DateTime) => d.getDayOfWeek == FRIDAY) -> "Fri"
    )

    def message(date: DateTime) =
    messages.find(_._1(date)).map(_._2).getOrElse("Default")

    println(message(new DateTime(2010, 3, 3, 0, 0, 0)))
    println(message(new DateTime(2010, 3, 4, 0, 0, 0)))
    println(message(new DateTime(2010, 3, 5, 0, 0, 0)))
    }

    Kolorowo: http://pastebin.com/gaxAsDV2

    Pozdrawiam.

    ReplyDelete
  4. Dzięki za ten ciekawy przykład. Masz rację, w Scali implementacja jest znacznie bardziej zwięzła (zresztą pewnie jak w każdym innym języku funkcyjnym). Mimo, że jest to bezpośrednie "tłumaczenie" dość zagmatwanej wersji w Javie, dzięki wyrażeniom lambda (i JodaTime) kod pozostaje czytelnym.

    Z ciekawości przepisałem Twój kod z użyciem collectFirst (i pattern matching). Niekoniecznie czytelniejsze, ale chyba ciekawe.

    ReplyDelete
  5. Kilka pytań:

    1. Dlaczego final? (wystarczy jakiś link do dobrego artykułu)

    2. Wspominasz o 'Clean Code' w tym wpisie. Zgadzasz się z założeniami i tezami zawartymi w tej książce?

    3.Wspominasz o Null Object ale bardziej w kontekście przekazywania takich obiektów do metod. Chciałbym jednak wiedzieć jak, w dobry sposób, zwracać 'obiekty nullowe' z metod. Na przykład mam metodę public User findUserByName(String name).
    Co zwrócić w przypadku nieznalezienia użytkownika: NullObject, wyjątek czy null'a (i dlaczego) ?

    Byłbym wdzięczny za wskazówki.

    Pozdrawiam

    ReplyDelete
    Replies
    1. Ad. 1.: zmienna lokalna final ułatwia analizę kodu (wiemy, że jej wartość nigdy się nie zmienia, raz przypisana zawsze wskazuje na to samo) oraz jego optymalizację przez JVM. Finalne pola są praktycznie koniecznością do implementacji typów "immutable"

      Ad. 2.: Niewątpliwie często książka jest bardzo "fundamentalna", ale tylko po to, by podkreślić jej tezy. Tak, zgadzam się z wytycznymi Wujka Boba.

      Ad. 3.: To zależy od kontekstu:

      * wyjątek, jeśli jestem absolutnie pewien, że użytkownik o takiej nazwie istnieje. Jego brak oznacza poważny błąd logiczny/systemowy/programistyczny (np. pobieramy z bazy użytkownika, który jest właśnie zalogowany, a tu nie ma go w bazie)

      * Null-object jest trudny w przypadku obiektów niosących jakąś wartość. Czy atrybuty Null-użytkownika powinny być null-obiektami? A co, jeśli taki obiekt przeniknie do logiki biznesowej? Czasem warto mieć taką abstrakcję (np. NiezalogowanyUżytkownik zamiast null), ale trzeba być czujnym. Znacznie łatwiej, gdy np. metoda zwraca kolekcję. Wtedy wszystko jasne, zwracamy pustą kolekcję (swoisty null-object).

      * Optional z Guavy. IMHO najlepszy pomysł. Widać od razu, że metoda może zwraca, a może nie użytkownika (co nie jest niewidoczne w przypadku zwracania User). Niestety w Scali Option[User] jest znacznie wygodniejszy w użyciu

      * null - w ostateczności.

      Delete
  6. Mam jescze jedno pytanie (trochę z innej beczki):
    Jak, w dobry sposób, zaprojektować struktury danych (część M w MVC, model)?

    Spotkałem się z co najmniej dwoma podejściami:
    1. Dzielimy wszystkie dane na odpowiednie klasy (struktury danych) i tworzymy całą strukturę za pomocą zwykłej kompozycji.
    2. Tworzymy interfejsy, klasy abstrakcyjne i klasy implementujące te abstrakcje. Następnie stosujemy różne wzorce projektowe (np. dekorator), żeby poszczególne interfejsy połączyć w jedną
    dużą strukturę.

    I teraz zestaw pytań:

    1. Gdzie można znaleźć jakieś informacje na ten temat?
    2. Czy stosowanie interfejsów (klas abstrakcyjnych) dla modelu to dobre rozwiązanie?
    3. W jaki sposób zaprojektować taką strukturę w taki sposób żeby możliwe było łatwe 'wyciąganie' (np. z bazy danych) fragmentów takiego modelu, potrzebnych w kontretnych przypadkach?

    Będę bardzo wdzięczny za wszelkie wskazówki


    Pozdrawiam

    ReplyDelete

Post a Comment