Razem z ludźmi z Wrocławskiego JUGa i Wrocławskiej grupy kunszt organizujemy też otwarte CodeRetreat dla Wrocławia! Wydarzenie prawdopodobnie odbędzie się 23 października, a o szczegółach poinformuje między innymi na tym blogu.

Ale dlaczego warto poświęcić sobotę i przyjść? Będziesz miał okazję ćwiczyć!

Dlaczego jest to ważne? Zapraszam do obejrzenia wideo z prezentacji Corey’a (jeden z pomysłodawców CodeRetreat).

Practise

Daj znać innym

W skrócie: Jest to cały dzień programowania w parach ćwicząc Test-Driven Development. Nacisk kładziony jest na to jak pracujemy (w przeciwieństwie do tego nad czym pracujemy). Słowo klucz: kata

Czym moje warsztaty różniły się od prawdziwych „CodeRetreat”?

• Były to warsztaty zamknięte (tylko dla pracowników)
• Były zorganizowane w dzień roboczy (a nie w sobotę)
• Odbyło się tylko 5 sesji (a nie 6-7)
• Nie poszliśmy na koniec do pubu

Z informacji zwrotnej uzyskanej od uczestników wynika, że warsztaty się podobały

Zresztą proszę poczytać co mieli do powiedzenia uczestnicy:

Na pewno ten czas spędziłem ciekawie. Programowanie w parach pokazało, że każdy może wnieść od siebie coś nowego, rzucić światło na pewne aspekty, których się nie dostrzegało. W każdej sesji rodziły się nowe pomysły i podejścia do rozwiązania wciąż tego samego problemu. Była to dobra okazja do wymiany doświadczeń a także do praktycznego wykorzystania TDD. Polecam każdemu wzięcie udziału w takich warsztatach. Uważam, że jest to czas dobrze wykorzystany. - Michał

Ciekawe i dobrze przygotowane szkolenie. Dużym plusem jest to, że szkolenie to jest w formie warsztatów. Forma ta pomaga wymieniać doświadczenie i uczyć się od siebie nawzajem, co uważam, za największą wartość, jaką wyniosłem. Poza tym, była to dobra zabawa. – Janek

Pierwszy raz uczestniczyłem w tego typu warsztatach i muszę przyznać, że jestem miło zaskoczony.
Kilkukrotne rozwiązywanie jednego problemu  (prostego swoją drogą), ale z różnymi osobami prowadziło do różnych ciekawych wyników.
Programowanie w parach ma w sobie moc, bez względu na to, czy programuje się z kimś słabszym czy lepszym – oto jeden z moich wniosków po tych warsztatach.
Warsztaty przygotowane dosyć rzetelnie, zarówno od strony technicznej ( sala, komputery ), jak i merytorycznej – całkiem sporo wiedzy zostało przekazane – wiedzy, która według mnie powinien posiadać każdy programista.
Jednym słowem – brawo Grzegorz! Wyszło świetnie, pomimo że pierwszy raz organizowałeś tego typu zajęcia. Mirek

Dziękuję za możliwość wzięcia udziału w warsztatach. Bardzo podobała mi się ich forma i zróżnicowanie doświadczenia uczestników. Choć byłem w mojej ocenie najmniej zaawansowanym uczestnikiem warsztatów poradziłem sobie z pomocą kolegów i koleżanek z zadaniem jakie mieliśmy do wykonania. Samo zadanie również było bardzo interesujące i wciągające. Czas podczas warsztatów upływał niemiłosiernie szybko lecz mimo to w kolejnych krokach udawało się dochodzić co raz to dalej. Warsztaty uświadomiły uczestnikom, a na pewno mi, że jeżeli chcę tworzyć poprawny kod to bez wątpienia powinienem wychodzić o tworzenia testów, a kończyć na implementacji (przekonałem się do tego już podczas drugiej sesji). Uważam, że osoba przygotowująca warsztaty zachowała się profesjonalnie i swoją postawą zachęcała do działania. Chciałbym, aby takie warsztaty były organizowane cyklicznie i uważam, że warto zainteresować nimi większy odsetek pracowników mających możliwość wykorzystania tej wiedzy w codziennej pracy.
Jeszcze raz dziękuję za ciekawy dzień pracy. Grzesiek

Wydarzenie było dość kameralne – uczestniczyło w nim 6 osób + ja.  Programowaliśmy w Javie.

Przez pierwsze 3 sesje byłem obserwatorem. Było to o tyle fajne, że mogłem podglądać co robią ludzie i na retrospekcjach po sesjach poruszać tematy dotyczącego tego, co widziałem że działo się u innych.

Ostatnie 2 sesje sam aktywnie kodowałem w parze i o ile pozwoliło mi to poczuć na własnej skórze to co robili uczestnicy, to bardzo utrudniło dawanie wskazówek odnoszących się do tego co działo się w innych parach.

Na retrospekcjach poruszaliśmy temat związane z:

• Różnymi pomysłami na zakodowanie rozwiązania
• Jak pisać czysty kod
• Jak efektywnie programować w parach (np. ping-pong programming)
• Test-driven development, TDD as you meant it

Warsztaty zaczęliśmy, krótkim wstępem, gdzie

• Każdy miał szansę się przedstawić
• Przedstawiłem plan dnia
• Opowiedziałem trochę skąd pomysł (QCon i wykład Corey’a Haines)
• Powiedziałem klika słów o Software Craftsmanship (care, practice, learn, share), manifest
• Przytoczyłem klika wskazówek na temat tego, jak programować w parach.
• Przypomniałem zasady TDD
• Omówiłem zasady „Gry w życie”

W czasie przerwy obiadowej przejrzeliśmy slajdy Sharpening the Tools

Code Retreat we Wrocławiu

Ponieważ warsztaty uważam za udane, myślę że warto zorganizować prawdzie „CodeRetreat” dla Wrocławia. Jeśli ktoś jest zainteresowany to proszę o kontakt.

Co jest niezbędne by to urzeczywistnić?

• Duża sala, gdzie wygodnie można siedzieć i kodować w parach przy laptopach.  (sponsor)
• Uczestnicy z laptopami
• Termin

Więc nie potrzeba chyba aż tak dużo?:)

A co mogłoby wydarzenie uczynić jeszcze fajniejszym

• Dodatkowe monitory, by wygodnie pracowało się na laptopach
• Obiad ufundowany przez sponsora
• Dostęp do neta
• Na zakończenie wyjście integracyjne, ufundowane przez sponsora

Jeśli ktoś ma pomysł jak powyższe rzeczy zdobyć a tym samym urzeczywistnić Wrocławskie CodeRetreat proszę o info w komentarzach

Linki:

• http://coderetreat.ning.com/profiles/blogs/how-to-run-a-coderetreat
• http://www.coderetreat.com/
• http://www.agileminds.be/workshop/2010/coderetreat/index.html

Daj znać innym

Egzamin zdawałem w http://www.prolearning.pl na ulicy Legnickiej we Wrocławiu. Jest tam OK, chociaż mogliby zainwestować w klimatyzację zamiast wiatraka.

Tak jak się spodziewałem najgorzej wypadłem z zagadnień „pamięciowych” – API contents.

Poniżej materiały, które mogą się przydać kolejnym pokoleniom programistów chcących się certyfikować

• http://www.amazon.com/SCJP-Certified-Programmer-Java-310-065/dp/0071591060 - Zdecydowanie polecam na spokojnie przerobić tą książkę. Może to zająć parę miesięcy

• Jako dodatkowa książka: http://www.amazon.com/Programmers-Guide-Java-SCJP-Certification/dp/0321556054/ref=pd_sim_b_1 – warto przerobić próbne egzaminy i pytania po rozdziałach.

Gdy już masz opanowaną teorię trzeba koniecznie przerobić jak najwięcej próbnych egzaminów.

• Testkiller Ltd. Study Guide dla SCJP 5.0 – wiele pytań się powtarza na prawdziwym egzaminie

• http://faq.javaranch.com/java/ScjpFaq

• http://faq.javaranch.com/java/ScjpMockTests

• http://examlab.tk/ – GUI bardzo podobne do tego na egzaminie

Generalnie polecam wykupić voucher i zacząć czytać książkę (również rozwiązując testy po rozdziałach). Po przeczytaniu książki przerobić całego test killera. Następnie zarejestrować się na egzamin za miesiąc i przez ten miesiąc rozwiązywać próbne egzaminy.

W ten sposób powinno spokojnie udać się zdać na 100% czego serdecznie życzę

Daj znać innym

Daj znać innym

Napiszę teraz co nie co o sesji Software Craftsmanship, Beyond The Hype. Sesję poprowadził Corey Haines, który bardzo dosłownie potraktował idee „Journeyman” i jak możemy się dowiedzieć (http://www.coderetreat.com/) rok 2009 spędził podróżując po stanach ucząc programowania w parach w zamian za wikt i opierunek.

Jeśli nie słyszałeś jeszcze o Software Craftmanship, tutaj możesz przeczytać manifest. Jeśli agile jest o tym jak dostarczać oprogramowanie wysokiej jakości, to Software Craftmanship jest o tym jak kształcić deweloperów o wysokich kwalifikacjach.  Corey opowiadał o tym, co w ostatnim czasie działo się w środowisku i tak:

• Rozpowszechniła się idea Code Katas
• Temat jest poruszany na konferencjach, np. ścieżka w czasie QCon
• Coderetreat - może warto coś takiego zorganizować we Wrocławiu? Corey podróżuje z tym teraz po świecie, więc można by go spróbować zaprosić.
• Powstają User Groups – btw, mamy jakieś aktywne grupy w Polsce?
• Craftsman Swaps – firmy wymieniają się pracownikami, na tydzień lub dwa. Pracownicy mogą zobaczyć jak podchodzi się do wytwarzania oprogramowania w innych „warsztatach”. Ktoś słyszał o czymś takim w Polsce?
• Craftsman Journeys – Tak jak Corey, ludzie zaczynają ruszać na dłuższe podróże, podczas których spotykają się z deweloperami z różnych zakątków świata, kodując razem z nimi i wymieniając się doświadczeniem i technikami.
• Craftsman Spikes – firmy dają możliwość chętnym, przyjść i popracować u siebie przez parę dni. Np studenci mogą przyjść ze swoim problemem i nauczyć się czegoś od praktykujących deweloperów.

Daj znać innym

Właśnie skończyłem czytać rozdział 6 i chciałbym tutaj zamieścić tłumaczenie podsumowania tego rozdziału.

Obiekty prezentują zachowania (funkcje) i ukrywają dane – to sprawia, że łatwo jest dodawać nowe rodzaje obiektów bez potrzeby zmiany zachowań (funkcji) istniejących obiektów. Kolejną konsekwencją jest to, że trudniej jest dodać nowe zachowanie do istniejących obiektów (wszystkie obiekty muszą się zmienić).

Struktury danych prezentują dane i nie mają żadnego znaczącego zachowania (funkcji). To sprawia, że łatwo jest dodać nowe zachowanie obsługujące istniejące struktury danych, ale trudniej dodać nowe struktury danych (bo wszystkie funkcje muszą się zmienić).

W każdym systemie będziemy chcieli czasem mieć elastyczność w dodawaniu nowych typów danych, więc wybierzemy obiekty dla tej części systemu. Kiedy indziej, będziemy chcieli łatwości w dodawaniu nowych funkcji i dla tej części systemu wybierzemy struktury danych i procedury.  Dobry inżynier oprogramowania rozumie powyższe sprawy i bez uprzedzeń wybiera podejście, które najlepiej rozwiąże dany problem.
Co wy na to? Sam muszę to przemyśleć, na razie sugerowanie użycia struktur danych i procedur
wydaje mi się trochę podejrzane, ale z drugiej strony? ..

Daj znać innym

W TDD pracujemy w cyklach RED GREEN REFACTOR. Kiedy pierwszy raz spotkałem się z tym podejściem jednym z problemów było znalezienie odpowiedzi na pytanie: „Co i jak poprawiać w kodzie?„.

Jeśli też stawiasz sobie te pytanie, polecam Ci książkę Clean Code – można się z niej dowiedzieć wiele przydatnych rzeczy.

Tutaj znalazłem podsumowanie rozdziału 17, gdzie zebrane są wszystkie „heurystyki” i „brzydkie zapachy” związane z kodem.

Napisałem prościutki plugin do Eclipsa, który wyświetla listę tych heurystyk w okienku, dając nam możliwość sprawdzenia naszego kodu pod kątem tych heurystyk (oczywiście najpierw trzeba je znać i rozumieć)  – taka ściągawka. Jeśli jesteś ciekawy tego pluginu, daj znać na maila lub w komentarzach, wyśle  Ci

Daj znać innym

Wpis daje parę przykładów tłumaczących „prawo przeciekających abstrakcji”. Chodzi mniej więcej o to, że mimo iż korzystamy z abstrakcji, to by poradzić sobie w trudnych sytuacjach ciągle musimy rozumieć mechanizmy, które kryją się za abstrakcją.

All non-trivial abstractions, to some degree, are leaky.

Wszystkie nie trywialne abstrakcje, do pewnego stopnia przeciekają.

Np abstrakcja TCP pretenduje, że można coś przesłać przez sieć w sposób, który gwarantuje dostarczenie. Jednak TCP jest zbudowane przy użyciu protokołu IP, który takiej gwarancji nie daje. Korzystając z TCP możemy się więc spotkać z sytuacją, że coś nie zostaje dostarczone, żeby zrozumieć czemu musimy sobie zdawać sprawę z istnienia IP.

Daj znać innym

Napisanie Hello World okazało się szybkie i przyjemne (dobra integracja z Eclipsem).

Gdy znajdę więcej czasu to może napiszę jakąś prostą aplikację. Kilka pomysłów mam

Aplikacje można publikować na Android Market

Daj znać innym