Do DevDay uczuciem gorącym pałam. O czym zresztą wspomniałem na pre-party: że łaknąłem go jak kania dżdżu, tudzież jak świnia trufli. Który to tekst skądinąd strasznie drętwo z ust mych wypłynął.
Organizatorów – Rafała i Michała – z wielką chęcią do swojego Białegostoku ściągnąłem przed wakacjami na spotkanie naszej grupy .NET i było to zdecydowanie jedno z lepszych spotkań w minionym sezonie (z najbardziej zapadającym w pamięć after-party;) ). Dlatego też nie mogłem się doczekać tegorocznej edycji. Apetyt wzmógł upadek na motocyklu, przez który przez dwa tygodnie kicałem z zagipsowanym kulasem zastanawiając się czy aby na pewno dam radę wytrzymać 10h podróż do Krakowa. Dałem – więc git. I wróciłem, i żyję, więc git do ^. I niby wszystko super, niby wszystko zajebiście, ale… ale jakoś tak nie jestem w stanie entuzjazmem sikać, jak to miało miejsce rok temu.
Czemu? Sam do końca nie wiem… ale po kolei
Pre-party
Tak jak pisałem, dzień przed DevDayem odbyło się 90 spotkanie krakowskiej grupy .NET. Cóż za genialny pomysł! Zarejestrowała się ponad setka osób, to już właściwie druga konferencja :).
Mojej 3-osobowej ekipie udało się dotrzeć na miejsce kilka minut po rozpoczęciu prezentacji Michała Łusiaka. Zainteresowanie było jednak tak ogromne, że jedyne wolne stojące miejsca nie pozwalały ani widzieć, ani słyszeć prelegenta. Musieliśmy się więc obejść smakiem i ewakuowaliśmy się do pobliskiego pubu na browarka. I też było miło.
Po półgodzinnym chillu wróciliśmy na salę ABB, gdzie dane mi było po raz kolejny (przed-przed-ostatni) poopowiadać o Dependency Injection. Mówienie do tak ultra-pełnego pomieszczenia jest niesamowicie satysfakcjonujące i daje nieziemskiego kopa, więc wystąpienie zaliczam do udanych. A obecnym dziękuję za tak liczne stawienie się. Jednocześnie apeluję po raz N-ty: piszcie mi jak było:). Co prawda dostałem feedbacku więcej niż po jakimkolwiek innym wystąpieniu, ale “gimme gimme gimme”!
Po KGD to już wiadomo… browing tu, shoting tam, eccecera. Bez zbytnich szaleństw, ale było sympatycznie.
Prelekcje
BuildStuff w roku 2012 uświadomił mi, że na konferencje nie jeździ się tylko po to aby pooglądać sesje. A zeszłoroczny DevDay tylko mnie w tym przekonaniu utwierdził. Mimo to… właśnie ten element konferencji jakoś mi najbardziej w tym roku uwiera. Niby wszystko było fajnie, ale teraz, gdy analizuję wyjazd na chłodno, to “prelekcyjnie” wychodzi mi obraz nie do końca idealny. Zobaczcie sami:
Jackstones: The Journey to Mastery (Dan North)
Ta akurat prezentacja była mi znana, ponieważ powaliła mnie na glebę przy okazji CraftConf w Budapeszcie pół roku temu. Siłą rzeczy Dan nie zrobił na mnie aż tak wielkiego wrażenia jak wtedy (bo już to widziałem? bo była to pierwsza prezentacja w ciągu dnia? bo Dan miał kaca?), ale i tak słuchało się bardzo przyjemnie.
W skrócie: zastanów się, człowieku, jakie czynniki mogą wpłynąć na twoje bycie lepszym programistą i wykorzystaj je.
Kartka: zielona (good).
Why No Code Reviews? (Enrico Campidoglio)
Enrico z Tretton37 rozpoczął w zaiście wielkim stylu: przez połowę prezentacji można było autentycznie boki zrywać. Bardzo trafnie i wesoło przedstawiał swoje poglądy na temat “dlaczego code reviews są potrzebne i dlaczego stosujemy je rzadziej niż powinniśmy”.
Mogliśmy zastanowić się chwilę nad ciekawą analogią: jak to możliwe, że czasami kod wpada na produkcję bez ani jednego review, podczas gdy w branży książek czy czasopism po prostu nie ma takiej możliwości i tam KAŻDE SŁOWO jest czytanie przez przynajmniej kilka osób? Moja akurat osobista odpowiedź jest prosta: bo do książki nie da się napisać unit testów. Ale nieważne.
Po kilkunastu minutach rozrywki na naprawdę wysokim poziomie nastąpił niestety spadek. Po interesujących refleksjach odnośnie omawianego tematu przeszliśmy bowiem do omawiania jednego konkretnego narzędzia (Upsource). A potem do omawiania drugiego konkretnego narzędzia (Gerrit). Minuta z jednym czy drugim toolem byłaby spoko, ale pól prezentacji na pokazanie jak dodaje się komentarz do kodu to moim zdaniem zbyt długo. Tym bardziej że nie dowiedzieliśmy się na przykład KIEDY zdaniem prelegenta powinno się robić code review? Albo KTO powinien to robić: tylko seniorzy juniorom, czy może każdy każdemu? Albo jaki kod powinien podpadać pod review a jaki nie? Albo jak to się ma do procesu build/release?
Świetnie słuchało się pierwszej części, ale zbyt wiele pytań pozostało bez odpowiedzi.
Kartka: żółta (so-so).
Defensive Programming 101 v5 – Common Security Mistakes in Web Applications (Niall Merrigan)
Ta prezentacja odbywała się równolegle z Enrico, więc jej nie widziałem, ale z tego co słyszałem to była niesamowita. Sam nie mogę się doczekać jej publikacji na dewdejowym jutubie.
So Long, and Thanks for All the Tests (Seb Rose)
Jeśli jest prezentacja o testach to nie może mnie na niej zabraknąć. Niestety tym razem: pudło. Do połowy prezentacji nie potrafiłem zrozumieć o co prelegentowi chodzi. Rozumiałem słowa, ale nie widziałem w nich głębszego sensu. Kolejne slajdy wydawały mi się bezsensownym zlepkiem oklepanych cytatów i stwierdzeń odnośnie automatycznego testowania oprogramowania. Bez wizji, bez wytyczonej ścieżki. Ot takie gadanie dla gadania. Więc poszedłem na fajkę i… zająć kolejkę na lunch :).
Kartka: czerwona (bad) (tak naprawdę do “pudełka ocen” nie wrzuciłem żadnej)
React + NPM for Great Good (Rob Ashton)
Temat był nieważny: tutaj szedłem na Roba. Liczyłem na jechanie po Angularze, na żywiołowość, humor i ogólną zajebistość. I się nie przeliczyłem!
Dowiedziałem się co to jest React, a wcześniej nie miałem o tym zielonego pojęcia. Posłuchałem jak to Rob polałby benzyną i podpalił programistów korzystających z usług Angulara. Popatrzyłem na ponies i na to jak Rob śmiga po VIMie. Wreszcie: pośmiałem się z Robowego Maca, który zawiesił mu się na koniec prezentacji.
Było krótko, ale było git. A “brakujący” kwadrans wypełnił kabaret Q&A.
Kartka: zielona (good).
Hacking Your Doorbell (Karl-Henrik Nillson)
Przyznam szczerze: to na tą prezentację czekałem najbardziej. Już z rok temu planowałem zabrać się za poznawanie netduino i hackowanie własnego mieszkania. Wtedy zapał mi minął, ale byłem przekonany, że tym razem po powrocie do domu będę mógł od razu wziąć się do roboty. W końcu w opisie sesji mamy: “how to get started hacking hardware in a Microsoft/C# .NET (well mostly) environment TODAY”. Niestety nic takiego się nie stało. Owszem: zobaczyliśmy jak prelegent uruchamia dzwonek do drzwi przez stronę WWW. Owszem: zobaczyliśmy jak prelegent dodaje “?action=mute” do query stringa powodując zamilknięcie dzwonka na wieki. Zobaczyliśmy nawet kawałek kodu w C# oraz “fizyczno-techniczno-elektroniczny” wykres tegoż dzwonka. Ale co z tego? Wiem tyle co wiedziałem wcześniej. A całość jakoś niesamowicie porywająca też wcale nie była.
Kartka: żółta (so-so)
It Doesn’t Work That Way in Enterprise (Peter Smith)
Nie miałem pojęcia o czym będzie ta prezentacja, spodziewałem się “jechania” po tzw “enterprise”. I dokładnie to otrzymałem. Mimo to… zupełnie, wcale a wcale, ani trochę mi się nie podobało. Usłyszeliśmy kilka anegdotek o tym jak to źle jest w “enterprise” i radę “walcz z systemem albo się zwolnij”. Koniec.
Sam przekaz byłby dużo lepszy, gdyby zamiast suchych czarnych punktów na białym powerpoincie pojawiły się jakieś śmieszne obrazki. Prelegent miał możliwości “wokalne” aby ciekawie całość poprowadzić, ale niestety jakoś coś nie wyszło. To jedyna prezentacja, na której przysnąłem. Może dlatego że sam od lat głoszę na blogu hasło “jak ci się nie podoba to się zwolnij”?
Kartka: żółta (so-so), ale to tylko dlatego że jestem kurturarny nad wyraz
Software Architecture vs Code (Simon Brown)
Simona widziałem na CraftConf, ale z innym tematem. Tym razem nie podobał mi się niestety. Przez prawie godzinę mówił o tym, jak nie rysować diagramów. I o tym, że łowił ryby i nie mógł nic złowić. I że w końcu złowił (yaaaay), ale oszukiwał bo złowił z łódki a nie z brzegu (buuuuuu). I że napisał kawałek kodu który rysuje diagramy takie jak powinny one wyglądać. Tyle że dalej wyglądają brzydko. A tak w ogóle to napisał o tym książkę… Jakoś tak sobie. Warsztatowi prelegenckiemu nie mogę nic zarzucić poza jednym (i, niestety, dość ważnym): o co tu, kurde, chodzi?
Kartka: źółta (so-so)
After-party
Po ostatniej prelekcji udałem się z małżonką na krótki spoczynek. Jeszcze niedawno takie coś byłoby nie do pomyślenia: iść się zdrzemnąć w środku imprezy? Ale może po prostu się starzejemy.
Tak czy siak decyzja była prawidłowa. Późnym wieczorem dołączyliśmy do devdejowego grona w krakowskim pubie i bawiliśmy się do 3 rano. Cała knajpa programistów gadająca, krzycząca, pijąca, paląca, żrąca kebaby i zapiekanki: do wyboru, do koloru, co komu miłe. Bardzo interesujące i niezmiernie trudne do zreplikowania otoczenie. Chyba TO jest dla Devdeja unikatowe: że tak wielu ludzi podąża na imprezę aby pokisić się własnym sosie. I wtedy jest naprawdę fajnie.
To już jest koniec
Dlaczego zatem nie jestem AŻ TAK podjarany? AŻ TAK nabuzowany dev-energią? Może dlatego, że ubiegłoroczna edycja była dla mnie szokiem i ideałem? Może po prostu wtedy wszystkie elementy – i te zależne od załogi DevDay, i te od niej zupełnie oderwane – zgrały się idealnie?
Nie ma to większego znaczenia. I tak WSZYSTKIM PROGRAMIST(K)OM polecam wybranie się na tą imprezę. I tak był to świetny wyjazd. Poprowadziłem jedną z lepszych prezentacji w swojej karierze. Pogadałem, pochodziłem, popiłem i popaliłem z milionem fajnych ludzi – dzięki wszystkim za te wspólne kilka chwil. Czułem jakbyśmy w tym momencie wszyscy byli w polskim dev-centrum. Bo chyba… byliśmy, nie?
Wiem, że z wielką niecierpliwością czekam na DevDay ’15. Oby tylko udało się zarejestrować, bo w tym roku to miałem po prostu strasznego farta:).
A może w końcu sam zdobędę się na przygotowanie prezentacji po angielsku i wysłanie zgłoszenia, coby awansować z roli “fluffera” do roli gwiazdy? ;) We will see…
Tak czy siak: do zobaczenia za rok! I wielkie gratulacje dla Michała, Rafała i całej ekipy “debugging crew”. Jesteście zajebiści, dzięki!
Jechałem na DevDay pierwszy raz i mam niestety podobne odczucia, jeśli chodzi o poziom wykładów. Po takich nazwiskach spodziewałem się czegoś bardziej rewela-/rewolucyjnego. Szkoda, bo organizacyjnie naprawdę bez zarzutu, a klimat – niesamowity.
Ze wszystkich prezentacji, jakie usłyszałem w Krakowie, najlepsza była Twoja. Brawo. Naprawdę już czas na pokazanie się poza granicami Polski i awans do pierwszej ligi prelegentów IT :). Liczę na grubą prezentację na następny DevDay, po której trzeba będzie zbierać szczękę z ziemi. No i mam nadzieję też usłyszeć niedługo co nieco na ten temat, który zapowiadałeś (bodajże o architekturze webowej z użyciem komend – popraw mnie, jak się mylę :), ale temat wygląda super – mam nadzieję, że rozwiniesz, dlaczego nie korzystasz już z warstw typu repozytoria).
Hej!
No to trzeba przyznać, że wg. mnie straciłeś najlepszą prezentację. Defensive programming był naprawdę zabawny i sporo pokazywał nt. bezpieczeństwa w ogóle nie tylko w aplikacjach, ale również w życiu :).
Rob to Rob.
O dzwonku było beznadziejne. Jakoś tak – nie ten poziom, albo coś.
No akurat o enterprise wywarło na mnie pewne wrażenie. Bo oczywiście było “walcz z systemem”, ale było też jak z tym systemem walczyć. W każdym razie ja mam inne odczucia ponieważ w takim zepsutym i zgniłym enterprise siedzę. A zmienić pracę jest mi trudno, bo ciężko ostatnio znaleźć fajne remote :)
Dopiero w tej edycji udało mi się dostać na devday. Było bardzo fajnie, prawie wszystko dopięte na ostatni guzik. Ludzie przemili, aczkolwiek widziałem, że programiści zbijali się w zamknięte grupki i naprawdę ciężko kogoś nowego poznać. A myślałem, że głównie po to się tam chodzi. Ale mało kto tak właśnie podchodził i poznawał ludzi. Nie wiem jak późne afterparty, bo musiałem do domciu wracać po nocy, więc tam się nie załapałem. W każdym razie miałem przyjemność zagadać Cię z rana o motocykl – więc cieszę się, że miałem okazję zamienić z Tobą słowo :)
pmarek,
Stary, ależ się zarumieniłem przed monitorem, dzięki :).
O kolejnej prezentacji wkrótce napiszę gdy potwierdzą się najbliższe terminy, póki co szczątkowe info tutaj: http://www.maciejaniserowicz.com/speaker/
pawelek,
Tej prezentacji o security mocno żałuję, no ale trudno.
Co do enterprise i remote: jeśli serio szukasz remote to odezwij się na priv, Ultrico poszukuje ludzi :). I nie jest to enterprise.
A zamknięte grupki programistów to nawet rozumiem. Sam za bardzo “po ludziach” nie chodziłem, bo takie wyjazdy to dla mnie często jedyna okazja spotkać się ze znajomymi z innych miast i utrzymać z nimi kontakt i często wybieram to nad poznawanie nowych osób.
Rano po rozmowie o motocyklu trzeba było wspomnieć że jesteś “do wzięcia” zawodowo to byśmy od razu proces rekrutacyjny rozpoczęli :).
Cześć,
Odnośnie “Enterprise” to słuchając Pete’a miałem wrażenie jakbym przed chwilą przeczytał Twój ostatni wpis o rozwoju programisty. Wnioski trafne, do stosowania codziennie :)
Jeśli chodzi o “Defensive programming” to liczyłem na troszkę co innego, a mianowicie liczyłem na kod. Z racji tego, że część mojej pracy związana jest z “security” przedstawione pojęcia były mi znane. Nie zaszkodziło jednak przypomnieć sobie trochę na ten temat, a przy okazji zobaczyć trochę całkiem fajnego warsztatowo wystąpienia.
Ogólnie cały DevDay był tematycznie najbardziej miękkim ze wszystkich, ale może to przez mój wybór tematów. Brakowało mi jednak trochę “mięsa”, ale cóż, nie można mieć wszystkiego. Oczywiście najfajniej było ponownie wszystkich spotkać i pogadać.
Pozdro
a ja sie nie zgodze jezeli chodzi o miecho. w 90% jak jest miecho pokazywane to wychodze, dlaczego? bo przewaznie okazuje sie ze to miecho jest dla level 100 i rzadko sie zdaza by to miecho mialo rece i nogi w swiecie rzeczywistym.
Dla przykladu, jak by wygladal przyklad kodu broniacego przez SQL Injection… imo wystarczylo powiedziec co i jak, a nie pokazywac ze jak sie cos robi w bad old way to trzeba wykorzystac sql parameters.
w zeszlym roku, dalem polowe zoltych kartek, w tym, tylko jedna. jak dla mnie merytorycznie najlepszy dev day.
Mi akurat “mięcha” nie brakowało. Koncepcyjnie agenda wyglądała super i nie mogłem się doczekać tych prelekcji. W praktyce po prostu coś siadło i większość niestety nie dała rady jakdla mnie.
Gutek,
Masz rację, że zwykle jak jest mięcho to można się zanudzić. Tylko, że w tym właśnie cały szkopuł aby pokazać je w ciekawy sposób. Mi na przykład bardzo podoba się sposób Procenta z wykorzystaniem TDD do eksploracji bibliotek. Wiem, że tego nie da się wykorzystać w każdej prelekcji, ale coś zawsze da się wymyślić.
Jeszcze raz napiszę, że moje odczucia są odzwierciedleniem moich wyborów na DevDay, ale jednak czegoś mi brakowało. Troszkę za mało konkretów jak na mój ścisły umysł.
Maciek dobrze napisał, konferencja to sesje i ludzie.
Odnośnie sesji mam podobne odczucia co większość. To można było już usłyszeć od ludzi w przerwach między sesjami. Może oczekiwałem zbyt wiele po poprzedniej edycji, ale w tym roku było jakoś tak płasko, mdło i bez polotu. Faktycznie sesja Niall’a Merrigana była bardzo fajnie poprowadzona, ale to także tylko liźnięty temat. Zdaje się, że obliczana na większą ilość czasu, skrócona, aby zmieścić się w dewdejowym okienku.
Co do netduino to także czekałem na coś w stylu WOW, bo swego czasu mocno byłem zaangażowany w projekt z wykorzystaniem micro frejmłork (chwilowo leży w szufladzie, czeka na trochę większą ilość wolnego czasu). Niestety dzwonki, diody i przyciski przerobiłem już dawno, więc… czytałem twittera ;)
Organizacja konferencji to inna bajka, oczywiście na najwyższym poziomie, pełna profeska na światowym poziomie. Mihcal i Rafek (jak i reszta zespołu) jak zwykle dali wszystko z siebie.
A klimat… Zajebisty… tego mi brakowało… szkoda tylko, że ten czas tak zapierniczał jak szalony i nie zdążyłem wszystkich zaczepić, pogadać… Cholercia, nawet z Tobą Maćku nie dałem rady… Ech… :)
Z tymi grupkami programistów, to nie do końca się zgodzę. Sam podchodziłem do wielu różnych, słuchałem, zagadywałem itp. itd. i… to właśnie ten element, to było dla mnie największe “mięcho” tej konferencji.
To własnie możliwość spotkania, podyskutowania, albo zwyczajnie posłuchania mądrzejszych od siebie sprawiła mi najwięcej frajdy :D
A co do sesji? Wiele zostało powiedziane podczas przerw, a gdyby ktoś miał ochotę przeczytać recenzję tych sesji, na których byłem, to zapraszam do mnie na bloga. Jako, że byłem również na warsztatach u Dana, to rozbiłem to na dwie części :)
http://zchpit.blogspot.com/
pozdrawiam
P.
dario,
No niestety faktycznie nie udało się pogadać. U mnie problem z takimi wyjazdami jest jeden: to często jedyna okazja żeby spotkać się ze znajomymi, z którymi znam się jeszcze z czasów studenckich a teraz nasze drogi się rozeszły.
zchpit,
Ciekawe, dzięki za linki! Fajnie poczytać o warsztatach.
Ciekawe, mi się prelekcja Simona Browna od strony merytorycznej bardzo podobała.
Model C4 znam już od dłuższego czasu i moim zdaniem ma najlepszą czytelność w stosunku do skomplikowania samego modelu. Problem z nim jest taki, że nie ma on sensu, jeśli narysujemy monolityczną, warstwową aplikację.
I tu pojawia się sendo tego, co Simon przekazywał: przestańmy myśleć warstwami, zacznijmy komponentami. Warstwy, jako dogmat, zrobiły w głowach developerów równie dużo złego, co dobrego. Dlatego proponuje on skupienie się na pionowym podziale systemu na komponenty odpowiadające funkcjonalności.
Czy to jest coś nowego i dziwnego. Zdecydowanie nie, dwa przykłady z okolic DevDay’a:
– Na czwartkowej prelekcji Procenta ktoś z wielkim zdziwieniem pytał, czy naprawdę ma sesję ORM’a w kontrolerze. Zdziwienie to prawdopodobnie wynikało z założenia, że wszystko trzeba pchać przez wszystkie warstwy. Bez rozróżnienia na proste i złożone komponenty, czy query i commandy.
– React.js – pokazywany przez Roba, stosuje podział aplikacji właśnie na pionowe komponenty (http://facebook.github.io/react/docs/reusable-components.html). Nie dzielimy: prezentacja, logika, serwisy; tylko feature taki, feature siaki, feature owaki.
Co o tym myślicie?
Szabl,
Ayende w 2009r ciekawie pisał na ten podziału “pionowego”: http://ayende.com/blog/3895/application-structure-concepts-features
Jego postów o tym było więcej, ale niestety kategoryzacja/tagowanie na tym blogu nie jest zbyt pomocna.
Procent,
dzięki za linka, mądre rzeczy.
Opisywane przez Ajende podejście jest jak najbardziej słuszne, tyle, że nie opisuje sytuacji, kiedy kolejny feature nie wpada dobrze się w istniejącą architekturę, im dalej w projekt tym takich więcej i albo męczymy się z tym co mamy, albo to zmieniamy i rozbudowujemy, czyli implementacja feature’a zawiera elementy redesignu. Wraz ze wzrostem aplikacji albo zrobimy z tego designu przerażającą strukturę, albo podzielimy ją na logiczne komponenty.
Ok, nie chce rozpoczynać wielkiej dyskusji na ten temat, bo nie ma tu jednego słusznego podejścia, a warto czerpać z niejednego źródełka, żeby ostatecznie zrobić po swojemu, najlepiej w konkretnym kontekście.