Jakub Binkowski - dot or not

Wnioski po MTS 2008

Microsoft Technology Summit 2008 zakończył się. Niestety, co bardziej aktywni blogerzy już dawno zdążyli opisać swoje wrażenia, więc moja relacja byłaby równie gorąca i na czasie co otwierająca MTS sesja o historii wstążki w Office 2007. Dlatego nie napiszę kolejnej relacji, a kilka wniosków, jakie wyciągnąłem z tej konferencji.

Jak w przyszłości wybierać sesje?

1. Sprawdzeni prezenterzy.
   Są takie osoby, na których sesje można pójść na ślepo. W moim przypadku byli to Tadeusz Golonka, Bartosz Pampuch i Tomasz Kopacz. Żaden z nich mnie nie zawiódł. Po MTS do listy doszło jeszcze jedno nazwisko - Bartłomiej Zass.
2. Wybierać tematy, o których nic lub prawie nic nie wiesz.
   Prawda znana od lat... Tylko nie wiedzieć czemu, zawsze przy rejestracji o niej zapominałem i wybierałem znane mi tematy. Bo niby poziom 400, więc pewnie dowiem się wielu nowych szczegółów. Na MTSie trochę przypadkowo wybrałem się na sesję o programowaniu mobilnym. Kiedyś trochę bawiłem się Compact Framework 3.5, ale krótko i bez robienia jakiś zaawansowanych rzeczy. I ta właśnie sesja okazała się być idealna dla mnie - Bartłomiej Zass bardzo ciekawie zaprezentował, jak wielkie możliwości daje CF 3.5 + Visual Studio 2008 w zakresie programowania na platformę Windows Mobile. Nie zdawałem sobie sprawy, że takie czynności jak odczytywanie pozycji przez GPS, interakcja z telefonem (SMSy, telefony), czy zaawansowana emulacja urządzenia (utrata zasięgu, rozładowanie baterii) są tak proste w realizacji.
3. Nie sugerować się zbytnio poziomem.
   Niestety, nie zawsze sesje bywają rzeczywiście na takim poziomie, jaki jest deklarowany. W przypadku wyboru prezentacji "Wydajne aplikacje ASP.NET w świecie Web 2.0" kierowałem się poziomem 400 i... bardzo się zawiodłem. Na początku dowiedzieliśmy się, jak uruchomić na stronie ASP.NET AJAX ("a teraz wstawiamy kontrolkę UpdatePanel"), co to jest LINQ i LINQ2SQL oraz jak zrobić wydajne stronicowanie. Jedynym przykładem na poziomie był Single Sign On dla kilku aplikacji webowych (na przykładzie własnej witryny ASP.NET i Community Servera).
4. Nie sugerować się zbytnio tematem.
   Czasami bywa tak, że nie do końca precyzyjnie sformułowany temat może błędnie zachęcić lub zniechęcić do zapisania się na sesję. W moim wypadku o mały włos zrezygnowałbym ze świetnej sesji Bartka Pampucha pt. ".NET bez wizardów – sposoby tworzenia i dynamicznego aktywowania komponentów w aplikacjach", gdyż po przeczytaniu tematu, nie za bardzo wiedziałem o czym będzie sesja.
5. Nie sugerować się zbytnio firmą prezentera.
   Często gdy prelegent pracuje w dużej, renomowanej firmie, to wydaje nam się, że wiedza, jaką może nam przekazać będzie wyjątkowa. Zwłaszcza kiedy tą firmą jest... Agencja Bezpieczeństwa Wewnętrznego, a tematyką "Bezpieczeństwo serwisów WWW – praktyczne uwagi o implementacji zaleceń DBTI ABW w ASP.NET". Trochę naiwnie uznałem, iż ABW posiada jakąś tajemną wiedzę z zakresu zabezpieczeń i przekaże ją nam podczas sesji. Naiwny ja! Sama prezentacja była jak najbardziej w porządku, ale rewolucji w moim postrzeganiu bezpieczeństwa aplikacji ASP.NET nie spowodowała.

Cechy najlepszych sesji i prezenterów

1. Nic nie zastąpi doświadczenia. Niestety.
   Cóż, nie zaskoczę nikogo twierdząc, że im większe doświadczenie ma prezenter w danej dziedzinie tym zrobi lepszą prezentację. Opisanie dziesiątek teorii, wykonanych badań i najlepsze zebranie materiału z książek, nie zastąpi własnych przemyśleń i rzeczywistych problemów. Świetnym przykładem jest tutaj Tadeusz Golonka, mający przynajmniej kilkunastoletnie doświadczenie w prowadzeniu projektów i zespołów. Na MTS mówił o zarządzaniu ryzykiem ("Efektywne zarządzanie ryzykiem bez/z Team Foundation Server 2008?"). Temat niby ważny i znany w teorii, ale w praktyce ograniczający się do zrobienia listy ryzyk i umieszczenia jej w czeluściach dokumentacji projektu, której nikt nie czyta. Na początku T. Golonka "pocieszył" publiczność - większość kierowników, z którymi miał kontakt nie zarządza ryzykiem w projektach i nie robi tego, bo nie wie jak. A więc ja, skromny programista, miałem też prawo mieć o tym pojęcie, delikatnie mówiąc, mgliste. Następnie, pokazał w praktyce, jak powinno takie zarządzanie wyglądać.
2. Zaskoczyć publiczność.
   Nic tak nie zapada w pamięci, jak prezentacja inna niż wszystkie. Po CodeCamp 2008 w Krakowie oraz MTS widzę, że Bartosz Pampuch jest specjalistą w tej dziedzinie. Na CodeCamp była prezentacja o agile... poprowadzona w stylu agile, gdzie zespół (publiczność) decydował o omawianych zagadnieniach. A na MTS był... rzutnik z dotykowym ekranem (WTF?) oraz prezentacja w WPF zamiast PowerPoint. Nie ukrywam, że przez pierwsze 5 minut prezentacji nie słuchałem w ogóle Bartka tylko zastanawiałem się, jakim cudem zwykły nieduży rozwijany ekran rzutnika może reagować na gesty dłoni?! Odpowiedź była prosta - http://www.cs.cmu.edu/~johnny/projects/wii/. W skrócie: reakcja nie na gesty dłoni, tylko na lampkę na podczerwień; nie ekran dotykowy, tylko kamera na podczerwień śledząca do 4 punktów (kontroler Wii) i przesyłająca dane przez bluetooth do komputera + soft zamieniający obraz na ruch myszki. Koszt: ok. 100 zł. Wrażenia publiczności: bezcenne.
3. Nie tracić czasu.
   Dobrym przykładem "czasopożeraczy" są kawałki kodu pisane na żywo. Ale jak się ich pozbyć? Nie można usunąć z prezentacji przykładów, bo bez nich trudno pokazać, jak działa jakaś technologia. Z drugiej jednak strony, teksty w stylu "a teraz dodajemy referencję do projektu... czekamy aż się pojawi okienko... i nadal czekamy" lub "a teraz kompilujemy... czekamy... aplikacja się uruchamia..." nie pobudzają specjalnie słuchaczy.
   Bartosz Pampuch świetnie i niezwykle prosto sobie z tym poradził - cały pisany kod nagrał wcześniej jako screencast'y i po prostu puszczał je jako przykłady. Dzięki temu - kod zawsze działał, dłuższe i mniej ciekawe fragmenty obejrzeliśmy w trybie fast-forward, a ważniejsze momenty powoli. Nie można nie zauważyć w tym momencie świetnego przygotowania Bartka. Każde nagranie miało idealnie dobrane tempo, tak że komentarz dokładnie mieścił się w wyznaczonych ramach. Co więcej, cała sesja była świetnie rozplanowana, nic nie było pominięte lub przegadane. Sam jakiś czas temu miałem przyjemność prowadzić prezentację na spotkaniu WG.NET o podobnej tematyce (AOP i DI). W pewnym momencie trwania sesji Bartka stwierdziłem, że to co mi zajęło pół godziny, on powiedział w 5 minut. Ogólnie - wielkie brawa za tą prezentację!
4. Wciągnąć publiczność do prezentacji.
   Interakcja z publicznością bywa ryzykowna, nie mniej jednak dobrze poprowadzona potrafi bardzo skutecznie przykuć uwagę. Tak było w przypadku sesji Bartłomieja Zassa pt. "Programowanie mobilne". Pytanie: jak dobrze zilustrować przykład reagowania na zdarzenia smartphona, np. w postaci przychodzącego SMSa? Odpowiedź: napisać aplikację zliczającą SMSy, pokazać ekran komórki na rzutniku i zachęcić publiczność do głosowania "czy obiad był dobry?". Zabawa była ciekawa, zwłaszcza gdy okazało się, że SMSy o treści innej niż przewidziana wyświetlają się jako nowe wiadomości, co można łatwo wykorzystać (wbrew planom prezentera) do zorganizowania chat'u na żywo na wielkim ekranie sali kongresowej :).

Opublikowane 12 października 2008 00:07 przez jakubin