Na parking dotarliśmy o 0850 po 2 godzinach podróżny na dystansie 170km (widocznie gdzieś po drodze nastąpiło lokalne zagięcie czasoprzestrzeni). Następnie udaliśmy się do punktu rejestracji na 3. piętrze...
STOP!
Przepraszam, zapomniałem, że blog to nie zeszyt do polskiego, a post to nie sprawozdanie z wycieczki do muzeum w 4. klasie podstawówki;P
Na wstępie gratulacje i uznanie dla organizatorów za rozmach oraz podziękowania dla wolontariuszy.
Chciałbym podzielić się przemyśleniami z kilku prezentacji:
Pisz po pijaku, przeglądaj na trzeźwo
Bezkompromisowa i nonkonformistyczna forma. Wspaniała interakcja z publicznością, bez puszenia się i pokazywania jaki to ja jestem mądry. Doskonałe zakończenie dnia.
W momencie kiedy Piotr wniósł sześciopak piwa i żołądkową (bo poprzednicy rozdali wszystkie gadżety przeznaczone na nagrody dla uczestników) pomyślałem tylko: "wiedz, że coś się dzieje":)
Na prezentacji mieliśmy błyskotliwą syntezę dwóch - popularnych ostatnio w "miękkim" IT - koncepcji:
- Model mózgu składającego się z "procesorów" Rich i Linear
- Model kompetencji Braci Dreyfus
Synteza polegała na postawieniu tezy, że ekspert w danej dziedzinie (piąty poziom Dreyfus) myśli nad problemem głównie "procesorem" Rich.
Nie wiem czy istnieją badania potwierdzające tą hipotezę, ale mnie się podoba, bo wydaje się brzmieć sensownie - póki co "kupuję to".
To do czego dotarłem w literaturze tematu i co wiadomo na pewno, to fakt, że ekspert na pewno czasem (w twórczym uniesieniu) myśli mniej, jest to zjawisko tak zwanego "lśnienia" polegające na tym, że podczas małej aktywności mózgu (zużycie energii) dochodzi do wykonania dużej i przełomowej pracy intelektualnej. Zjawisko to można obserwować na rezonansach.
Widziałem duże zainteresowanie publiczności, więc polecam materiały:
- Pragmatic Thinking and Learning: Refactor Your Wetware - dowiecie się z niej na temat modelu R/L oraz kilkunastu innych arcyciekawych i przydatnych w życiu sprawach. Autor dokonał syntezy wieli zagadnień z psychologii, socjologii, kognitywistyki podając je na tacy tak abyśmy nie musieli już sami szukać. Najlepsza książka jaką czytałem w zeszłym roku. Książki pisane przez programistów zawsze są dobre...
- Developing Expertise: Herding Racehorses, Racing Sheep - prezentacja na temat Dreyfus.
Materiał z kategorii "musisz zobaczyć".
- Wspinaczka do profesjonalizmu - artykuł na temat Dreyfus, który popełniłem w zeszłym roku dla Software Developer's Journal.
Miło było usłyszeć na prezentacji kilka odniesień do tekstu:)
Wracając do prezentacji Piotra, warto zapamiętać dwie rady praktyczne - techniki na uruchamianie Rich "procesora":
- odwracanie problemu: jeżeli nie wiemy jak zoptymalizować kod, to może zastanówmy się jak go spowolnić; jeżeli nie wiemy jak zaprojektować ergonomiczne GUI, to zastanówmy się jak zaprojektować je w sposób ultra-autystyczny.
Dlaczego to działa? Odsyłam do książki "Pragmatic Thinking and Learning" a później dalej...
- pair programming: niewiele osób uświadamia sobie, co się dzieje podczas programowania w parach. Mianowicie driver programując (czyli myśląc symbolicznie) pracuje na swoim "linearnym procesorze" a pilot zwolniony z tych czynności może uruchomić "procesor rich" i dokonywać myślenia syntetycznego na zasadzie nieświadomego pattern matching.
Play!Framework - ewolucja w świecie aplikacji webowych
Można opowiedzieć o frameworku webowym w sensowny i poukładany sposób tak aby było od razu wiadomo o co chodzi i kiedy oraz do czego mogę go użyć?
Można!
Brawa dla Wojtka. Konkretnie, na temat, dobrze dobrane przykłady kodu, dobre rysunki, szeroki zakres wiedzy i wszystko w 45 min! Wyszło lepiej niż filmiki na oficjalnej stronie frameworka.
Szczerze mówiąc to zacząłem rozważać Play jako narzędzie do pewnych klas problemów. Dzięki Wojtek.
Warto zwrócić uwagę na prezentację jako wzór do naśladowania:
- kod na Youtube z komentarzem na żywo prowadzącego (na pewno się nie wywali i nie będziemy tracić czasu na słuchanie nieśmiesznych tłumaczeń, że na prezentacji nigdy nie działa)
- szeroki wachlarz tematów do omówienia do wyboru wg zainteresowania słuchaczy (z uwagi ograniczony czas prezentacji).
Jeszcze raz brawo.
Quo Vadis IT
Pana Tomasza pamiętam jeszcze z zamierzchłych czasów studenckich, gdy przyjeżdżał na nasze rodzime uczelnie i priczował na temat technologii Microsoftu. Dałem się wówczas uwieść - ale tylko na chwilę:)
Prezentacja bardzo ciekawa, z uwagi na tematykę. Spojrzenie na branżę IT z wysokości 10km, co pozwala zauważyć powtarzające się w czasie patterny.
Widać było też na jakim poziomie i jak wnikliwie MS analizuje potrzeby oraz nawyki Userów (prywatnie i w pracy) oraz jak dobrze rozumie przemiany społeczne i mentalne zachodzące w czasie.
Miazga. My robaczki siedzimy sobie i męczymy się z kodzikiem, podczas gdy wysoko ponad naszymi głowami ktoś obserwuje i planuje rzeczywistość na kilkanaście lat do przodu.
Re-fuck-toryzacja czyli sprowadzanie sp****go kodu na właściwe tory
Paweł - dzięki za odniesienie do posta na temat radzenia sobie ze złożonością.
Muszę jednak zwrócić uwagę, że to co wyszło podczas refaktoryzacji to nie była Strategia a raczej zmodyfikowany Chain of Responsibility. Zmodyfikowany w taki sposób, że każde ogniowo łańcucha odpowiadało na pytanie "czy umiesz zająć się problemem", a jeżeli tak to "zajmij się". Czasem stosuję takie konstrukcję - łańcuch zarządzany przez "managera" - zębatkę.
Taka "zębatka" może być sama w sobie implementacją interfejsu strategii. Czyli mamy złożenie 2 patternów: strategia na wyższym poziomie (wariacje rozwiązania dużego problemu), a jedną z implementacji strategii może być taka zębatka zarządzająca łańcuchem małych ogniw, które coś tam sobie liczą (mikro problemiki wchodzące w skład jednego z wariantu rozwiązań problemów wyższego rzędu).
Teledysk na koniec - rotfl. Dobre zdjęcia, ładny dom:)
Co do mojej prezentacji, to jak zwykle: trema, przez którą wychodzi inaczej niż się planowało. Gadzi mózg podpowiada, że jeżeli stoisz sam bez broni i bez schronienia przed liczną grupą jakiś osobników to najpewniej za chwilę zginiesz. Ehh instynkt.
//=======================================
Przy okazji podzielę się jednak ciekawą obserwacją odnośnie psycho-akustyki (którą ostatnimi czasy nieco się interesuję). Z uwagi na wielkość sali, konstrukcję ścian, siłę oraz ustawienia nagłośnienia (i kilkanaście innych niesprzyjających uwarunkowań pomieszczenia) pojawił się efekt echa. Nie pogłosu, który jest do zniesienia a echa, które jest dla mówiącej osoby zabójcze.
Jako, że jestem tak zwanym słuchowcem (nie jest to takie proste, ale przyjmijmy na potrzeby posta, że jest coś takiego jak słuchowcy) to taki efekt nie jest tylko drażniący. U mnie niemal uniemożliwia mówienie. Przez chwilę myślałem, że się rozpłaczę ucieknę ze sceny hehehe.
Nie wiem czy ktoś włączył tłumienie fal obitych, ale nie widziałem nikogo majstrującego przy wzmacniaczach. Jednak po kilku minutach efekt echa zniknął. Ehh mózg ma niesamowitą zdolność do kompensowanie bodźców. A to co słyszymy jest tylko tym co nam się wydaje:)
13 komentarzy:
Tak naprawdę planowałem dalej nawiązać do Twojego wpisu i użyć słowa Polityka. Z resztą widziałeś, że klasy nazywałem Handler.
Chain of Responsibility to to też do końca nie był, bo w chainie każdy element powinien mieć link do następnego. Z resztą idea chain'a jest taka, żeby móc przetworzyć dane wejściowe wieloma elementami łańcucha. Tu po znalezieniu pierwszego pasującego był break (żeby zasymulować if...else). Więc koncepcyjnie to była jednak strategia :-)
Whatever.
@play framework - historia ciekawie zatacza koła. To co wydaje się główną siłą play'a już dawno zdąrzyło zaśmierdnąć w RoR czy CakePHP. Rzeczywiście jest tak jak piszesz - takie frameworki nadają się idealnie tylko do pewnej klasy problemów.
Masz rację - liczy się intencja, to co chcemy zrobić. Bo tak na prawdę wszystkie wzorce behawioralne i kilka innych są w uogólnieniu strategią robienia czegoś lub kilku rzeczy. Sprowadza się to po prostu wyniesienia czynności do rangi obiektu - takie meta-wzorzec. Różne wzorce ilustrują po prostu różne konteksty, czyli intencje.
Jako, że jest to mój konik, to pomęczę jeszcze temat...
Klasyczny łańcuch musi mieć w interfejsie ogniwa metodę ustawiającą następnik. Jak dla mnie jest to "brudzenie" modelu szczegółem związanym ze sklejaniem łańcucha. Dlatego preferuję zewnętrznego managera, który zarządza listą ogniw.
Nie mam przy sobie książki GoF, jak wrócę do domu za kilka dni, to sprawdzę, ale wydaje mi się, że łańcuch kończy po znalezieniu odpowiedniego do wykonania roboty ogniwa.
Ale przecież pattern-gestapo nie będzie nikogo ścigać jeżeli nie skończysz na jednym ogniwie. Na wyższych poziomach Dreyfus wzorce to tylko boczne kółka - ogólne formy, które można sobie modyfikować.
Gdyby jednak chciał wykonywać logikę przyrostowo (nie kończąc na jednym ogniwie), to użyłbym dekoratora ponieważ pozwala on wykonać logikę zarówno przed i po wykonaniu pracy przez inne elementy "matrioszki".
@Krzysiek
zatacza, zatacza...
i to jeszcze szerzej....
nie wiem czy pamiętacie MS Accessa?
Narzędzie nie do pobicia w kategorii CRUD:)
Niestety chłopacy z MS nie wpadli na pomysł aby osadzać Accessa w przeglądarce (exploderze) i zapewniać przeźroczyste łączenie z bazą po sieci.
Problem, którym piszesz jest klasyczny:
jeżeli użyjemy do proste problemu zbyt złożonego narzędzia to mamy problem.
ale
jeżeli do zbyt złożonego problemu użyjemy zbyt prymitywnego narzędzia to mamy problem do kwadratu.
I tak się zwykle zaczyna projekt... małą rzecz, użyjmy generatora cruda, później komplikacja domeny rośnie, zaczyna się rzeźba, ew modyfikowanie frameworka aby wspierał coś bardziej wyrafinowanego (a nie był pod tym kątem pomyślany). Uogólnienia w wyrafinowanym znowu wprowadzają mega-złożoność przypadkową.
"życia nie oszukasz..." - czasem trzeba po prostu przepisać.
Mi się Twój wstępny wstępniak bardzo podobał, wprawdzie siedziałem dość daleko, ale tremy nie zauważyłem :)
Szkoda, że dalszą ścieżkę wybrałem dość niefortunną - zdecydowanie nie wszystkie prezentacje trzymały poziom...
Za http://c2.com/cgi/wiki?ChainOfResponsibilityPattern:
- Do not use Chain of Responsibility when each request is only handled by one handler, or, when the client object knows which service object should handle the request.
- The chaining mechanism uses recursive composition to allow an unlimited number of handlers to be linked.
Czyli ja miałem rację ;-)
Ale i tak przyznaję Ci rację - w pewnych sytuacjach ja też nie widzę przeciwskazań, żeby skończyć na którymś konkretnym (np. serwletowy filtr security to dobry przykład). Ale jeśli z góry wiemy, że to będzie zawsze tylko jeden, to możliwość wołania rekurencyjnego jest niepotrzebna - wtedy lepiej wybrać to zewnętrznie. W końcu ta rekursja jest w chain'ie po to, żeby było trochę łatwiej zrealizować zachowanie na before i after następnego łańcucha. Jeśli masz wywołania na zewnątrz (tak jak w moim kodzie), to jest to trudniejsze (musisz mieć parę metod w ogniwie).
/s/następnego łańcucha/następnego ogniwa/
Tam do licha... jednak "nie ma cwaniaka na warszawiaka";)
Z Panami z c2 nie wypada polemizować.
Może i klasyczny Chain Of Responsibility Pattern musi mieć następnika w ogniwie, ale sposób implementacji nie jest tak istotny jak sama idea (pattern). Sam sposób implementacji to bardziej idiom.
Pomijając ten aspekt semantyczny, wersja z obiektem zarządzającym ma szereg dodatkowych zalet, takich jak zunifikowana obsługa sytuacji wyjątkowych czy mniejszy stos wywołań.
Po dwakroć racja!
Ha! Jednak znalazł się cwaniak na warszawiaka;P
@Sławek dzięki za dobre słowa, przeczytać je na Twoim blogu - naprawdę poprawiło mi humor. Postaram się nie schodzić poniżej tego poziomu na prezentacjach.
A co do tematu dyskusji, czyli w przypadku, kiedy mamy dokładnie jednego handlera, jakie wyjście proponujecie? Ja widzę coś takiego
for each handler {
if applies {apply and break loop}
}
i właśnie tu jest kłopot - ten break, który jest bardzo sztywny.
Jeśli kiedyś będę jednak chciał zmienić coś w zasadzie 'tylko 1 handler obsługuje', to będę musiał cały kod przerobić w przyszłości.
Łańcuch mógłby lepiej się wpasować, bardziej elastyczny, ale znów handlery trzymają w sobie informację, kto jest następny, a trzymanie takiej informacji powinno raczej należeć do zewnętrznej konfiguracji (np tak jak obecnie - fabryki). Mógłbym handlera pakować wtedy w obiekt Ogniwo, ale to już nie taka znów czytelność.
Którą opcję byście woleli czytając kod? Łańcuch czy for-if-break?
Aby jednocześnie zachować elastyczność oraz utrzymać obiekt zarządzający listą handlerów czasem robię takie coś:
Handler ma metodę boolowską isCritical (nazwa zależy od kontekstu, tutaj w kontekście łańcucha walidacji obiektów domenowych).
W przypadku walidacji właśnie, Manager łańcucha pyta ogniwo czy sugeruje ono zakończenie. Ogniwo może uznać, że błąd jest tak krytyczny, że nie ma sensu dłubać dalej. Ew. ogniwo mogłoby zwracać dotkliwość błędu (enum) a manager na podstawie dotkliwości decyduje co robić dalej.
Ew może być tak, że ogniwo zwraca obiekt Problemu, i w problemie siedzi rzeczona właściwość - dotkliwość.
Manager jest o tyle fajny, że może implementować interfejs Strategii. I tera mamy jedną strategię, którą da się elegancko obsłużyć listą handlerów. Inna strategia może kiedyś zawierać kłębowisko ifów, jeżeli logika okaże tak pokrętna.
A wracając do tematu głównego czyli samej Confitury, ja chciałbym dodać 2 inne pochwały za prezentacje (z tych co byłem):
- Prezentacja o soku z gumijagód, czyli o grywalizacji. Ciekawy trend, który wg mnie warto obserwować bo może niedługo zmienić wiele, zwłaszcza w internecie i marketingu (po części już zmienia).
- Prezentacja "Jak wycisnąć max z testów" - co prawda nie wszystko działało ale było OK i sporo się dowiedziałem. Do niezłych darmowych narzędzi do testów można dorzucić jeszcze Sikuli (sikuli.org)
Mam nadzieję że Organizatorzy kiedyś zamieszczą gdzieś video by można było obejrzeć prezentacje z innych ścieżek?
A przy okazji: wielkie buuuuuu dla prezentacji z e-point o ichniejszym generatorze kodu, w czasie jej trwania zzieleniałem ze złości prawie tak jak zielone jest logo e-point. :-)
Prześlij komentarz