Archiwum kategorii ‘Programowanie’

GOTO Aarhus 2011

czwartek, 20 Październik 2011

Drugi tydzień października spędziłem na konferencji GOTO w Aarhus. Jak zwykle było to bardzo intensywne doświadczenie ;)

W telegraficznym skrócie:

Niedziela

  • Warsztaty A user user manual z Chrisem Nodderem. Porady na temat tego jak tworzyć przyjazne i łatwe w użytkowaniu oprogramowanie + teoria na temat tego, jak zachowują się użytkownicy i dlaczego.

Poniedziałek

Wtorek

  • TODO

 Środa

  • TODO

Czwartek

  • Warsztaty „Evolutionary Architecture – How to Make it Work” z Martinem Fowlerem i Rebeccom Parsons
  • Warsztaty ”Influence Strategies for Practitioners” z Linda Rising

Piątek

  • Warsztaty ”Maintaining and Evolving Legacy Systems” z Frankiem Buschmann

Ogólne komentarze i podsumowanie:

W tym roku do materiałów konferencyjnych dołączone zostały dwie małe książeczki: „The 3 pillars of personal effectiveness” oraz „Priming Kanban” - oryginalne i fajne posunięcie.

I tak na przykład w „Priming Kanban” wyczytałem, co robić gdy osiągamy limit „work in progress„. Jest to moment na dyskusję. Do wyboru mamy albo powiększyć limit (co będzie skutkować zwiększeniem czasu, jaki jest potrzeby by historyjka przewędrowała od „koncepcji” do „wdrożenia”) albo usprawnić/wspomóc „wąskie gardło”. Np. gdy „testowanie” jest wąskim gardłem, może jako programiści możemy zautomatyzować wrzucanie nowej wersji na środowisko testowe? Tak czy inaczej, osiągnięcie limitu „work in progress” jest pretekstem do dyskusji.

Konferencja to również męczące wydarzenie (pełno wrażeń, codziennie integracja), nie mniej z niecierpliwością czekam na kolejną konferencję organizowaną przez Trifork, QCon 2012 w Londynie ;)

Extreme Startup zamiast wtorkowego dojo

środa, 14 Wrzesień 2011

Wczoraj zamiast „normalnego” dojo poprowadziłem mini warsztat Extreme Startup.

Podczas tego warsztatu zadaniem uczestników jest napisanie aplikacji webowej, która odpowiadać będzie na zapytania „wirtualnych” klientów. Uczestnicy warsztatu nie wiedzą, co ich czeka i z logów serwera muszą wywnioskować, czego chcą klienci.

Klienci będą między innymi pytać:

  • Ile jest 2 + 5?
  • Która z tych liczb się największa: 4, 234, 2, 4?
  • Jaki kolor ma banan?
Warsztat jest dość intensywny, jako że uczestnicy konkurują między sobą o to, kto zdobędzie najwięcej punktów. Na bieżąco na rzutniku wyświetlany jest aktualny ranking, co oczywiście wyzwala w uczestnikach chęć rywalizacji.
W zależności od pytania uczestnicy otrzymują różną ilość punktów. Gdy ich serwer odpowie źle, tracą punkty, a gdy ich serwer jest nie dostępny, tracą jeszcze więcej punktów.

W warsztacie wzięło 8 osób, zostały uformowane 4 pary. Zaczęliśmy o 1700 i około 50 minut zajęła nam sesja próbna, gdzie uczestnicy konfigurowali sieć tak, by móc połączyć się z serwerem i odpowiedzieć na proste zapytanie „Jak masz na imię”.

Około 18 zaczęliśmy ”prawdziwą” rundę z normalnymi pytaniami. Niestety z braku czasu, runda trwała tylko około 45 minut. Na przyszłość, „normalna” runda powinna trwać co najmniej 90 minut. Na potrzeby warsztatu przygotowane jest 6 zestawów pytań i wczoraj dobrnęliśmy tylko do trzeciego, a tak naprawdę mało który zespół miał poprawnie zaimplementowane wszystkie pytania z 2 pierwszych zestawów.

Z 4 zespołów tylko jeden pisał testy. Wszystkim zespołom poszło „podobnie źle” – zdobyły po około -2000 punktów. Prawdopodobnie gdyby warsztat trwał dłużej, to w miarę implementowanie poprawnych odpowiedzi dla kolejnych pytań, pary wyszłyby na prostą.

Pary, które używały „cięższych” serwerów aplikacji (jak Jetty ;) ) traciły sporo punktów podczas redeployu aplikacji. Niestety nikt nie pokusił się o rozwiązanie z load balancerem ;)

Technologie jakich używali uczestnicy

  • Scala
  • Node.js
  • Groovy
  • Smalltalk, a potem z powodu problemów Java
We wszystkich zespołach/parach uczestnicy grali rolę programistów. Żaden zespół nie „wprowadził” roli Product Ownera, który analizowałby logi i priorytezował pracę programisty (np. niektóre pytania były dużo prostsze niż inne, podobnie pytania miały różną ilość punktów, czasem wystarczyło zwrócić pusty string.).
Ogólnie chyba się podobało ;) .. Może powtórzymy ten warsztat za jakiś czas…
Ps. Wczoraj wyszła książka Lean Startup. Polecam.

 

 

 

Organizując światowy dzień CodeRetreat

środa, 14 Wrzesień 2011

Dziś rozpocząłem proces organizacji CodeRetreat Berlin w ramach światowego dnia CodeReteat.

Na razie założyłem tylko grupę na googlach i szukam chętnych do pomocy. Przed nami „trochę pracy”. Musimy znaleźć sponsorów, salę, przeprowadzić rejestrację, zorganizować obiad i załatwić wiele innych małych rzeczy. Damy radę! Po ostatnim CodeRetreat w Berlinie, ludzie są pozytywnie nastawieni :)

Światowy dzień CodeRetreat odbędzie się w sobotę, 3 grudnia 2011. Na razie na liście miast uczestniczących w projekcie nie ma żadnego miasta z Polski, mam nadzieję, że wkrótce się to zmieni ;)

3 grudnia, przez około 32 godziny, gdzieś na świecie odbywać się będzie CodeRetreat. W czasie przerw pomiędzy iteracjami będziemy łączyć się na wideo konferencjach z innymi lokalizacjami i na bieżąco będziemy wymieniać się wrażeniami i pomysłami.

Czy weźmiesz udział w światowym dniu CodeRetreat? W jakim mieście?

Coding Dojo (cz. 2)

wtorek, 26 Lipiec 2011

Ciąg dalszy informacji na temat naszego Coding Dojo..

Ostatnio eksperymentowaliśmy z innymi językami niż Java. Wypróbowaliśmy Clojure, Scale oraz Ruby. Kilka obserwacji:

Dojo zaczynamy z „czystym” projektem (startujemy od zera).

W przypadku Clojure i Ruby kodowaliśmy od zera. W przypadku Scali, zostało zaprezentowane i omówione gotowe rozwiązanie. Dużo bardziej podobało nam się kodowanie od zera, gdyż każdy miał szansę zrozumieć co się dzieje (dla wielu języki były obce), a bardziej zaawansowane osoby miały szansę zobaczyć krok po kroku sposób rozwiązywania problemu przez innych.

Prezentowanie gotowego rozwiązania raczej się nie sprawdziło, gdyż osoby dla których język był nowy nie do końca rozumiały co się dzieje, a dla osób zaawansowanych samo finalne rozwiązanie nie było aż tak ciekawe.

Ćwiczymy jedną rzecz na raz

Celem Dojo jest ćwiczenie. By robić to dobrze, warto skupić się na jednej rzeczy na raz. Średnim pomysłem jest ćwiczenie rozwiązania problemu w sposób obiektowy, gdy większość grupy nie potrafi nawet programować w danym języku (w takiej sytuacji można spróbować coś takiego: ekspert w danym języku ma klawiaturę i zamienia sugestie uczestników na temat rozwiązania obiektowego w kod).

Ponieważ spotykamy się tylko na jedną godzinę, dobrze jest wybrać za cel ćwiczenia coś bardzo konkretnego. Poniżej kilka przykładów:

  • Eksplorowanie  (nowego) języka (Ruby)
  • Eksplorowanie  (nowego) języka (Scala)
  • Ćwiczenie (szybkiego) cyklu RED, GREEN, REFACTOR w TDD (w języku, który zna grupa) (np. chcemy by cykl trwał mniej niż 3 minuty)
  • Ćwiczenie programowania obiektowego (w języku, który zna grupa) (np. chcemy by każda klasa przestrzegała zasad SOLID)
  • Ćwiczenie nazewnictwa (chcemy, by każda nazwa ujawniała intencję twórcy)
  • Ćwiczenie w pisaniu krótkich metod (np. max liczba linii to 4)
  • Ćwiczenie w obsłudze IDE (tylko skróty klawiszowe, refactoring)
Dojo może być formą Deliberate Practice. Dlatego sugerowany format jest następujący:
  • Jako grupa ustalamy konkretny cel na najbliższą godzinę
  • Jedna para pracuje, jej kod wyświetlany jest na rzutniku
  • Parę zmieniamy co 10 minut
  • W czasie 10 minut unikamy niepotrzebnych komentarzy, by nie rozpraszać pary. Para powinna komentować to co robi.
  • Po 10 minutach jest czas na (krótkie) pytania. Skupiamy się na naszym celu i o tym rozmawiamy (nie rozwodzimy się na temat SOLID gdy celem jest TDD).
  • Na koniec powinniśmy zrobić krótką retrospekcję: Czy osiągnęliśmy cel? Czego się nauczyliśmy? Co było fajne w formacie Dojo? Co możemy zrobić lepiej następnym razem?

IntelliJ IDEA – kolorki + szablon do testow

niedziela, 3 Lipiec 2011

Po zainstalowaniu IntelliJ IDEA, mamy do wykonania jeszcze dwie czynnosci ;)

1) Instalacja schematu kolorow: http://tedwise.com/2009/02/26/dark-pastels-theme-for-intellij-idea/

2) Dodanie szablonu do testow (Settings -> Live templates):

@Test
public void should$NAME$() throws Exception {
 // Given
 $END$

 // When

 // Then
}