Archiwum kategorii ‘Programowanie’

Refaktoryzując test do String Kalkulatora

czwartek, 29 Grudzień 2011

W ramach eksperymentu nagrałem wideo, w który refactoruje test do String Kalkulatora.

Wideo można zobaczyć tutaj: Refactoring of test

Filmik trwa 5 minut podczas których:

  1. Rozbijam jeden duży test na kilka mniejszych (by testy były łatwiejsze do zrozumienia, a gdy nie przechodzą by dokładnie było wiadomo co nie działa)
  2. Zamieniam assertEquals na assertThat (naturalniej się czyta)
  3. Zastępuje komentarze opisowymi nazwami testów (by samo zerknięcie do raportu w ciągłej integracji wystarczyło do zorientowania się, co się dzieje)
Klika używanych skrótów:
  • ctrl+y – usuwa aktualną linie
  • ctrl+c – gdy nic nie jest zaznaczone, kopiuje aktualną linię
  • alt+ctrl+v – wyciąga zaznaczone wyrażenie do zmiennej
  • ctrl+shift+f10 – odpala testy
  • ctrl+w – rozszerzające się zaznaczenie (naciśnij kilka razy, a zaznaczony obszar będzie rósł)
Kod który refaktoryzuję, pochodzi z mojego innego wpisu (Refactor my code step by step).

Refactor my code step by step!

niedziela, 27 Listopad 2011

Niedawno rozmyślałem nad skryptem w Ruby, który napisałem. Nie byłem z niego zadowolony. Co prawda działał, ale był dość „brzydki”.

Pomyślałem, super by było, gdyby ktoś mi pokazał jak napisać to lepiej.. „Refactor my code”.. Po krótkim googlowaniu okazało się, że jest już taki serwis: http://refactormycode.com/

O ile nazwa jest już zajęta ;) .. to mój pomysł miał jeszcze jeden istotny składnik. Założyłem, że ważne jest by „mój” kod nie tylko został poprawiony, ale żeby został poprawiony w małych kroczkach z wytłumaczeniem „dlaczego”, tak bym mógł się nauczyć i następnym razem sam napisać coś porządnie..

W gruncie rzeczy, to marzy mi się „coding dojo” rozproszone w czasie i przestrzeni. Piszę kod, który zapewne może zostać napisany lepiej. Chciałbym abyś wziął ten kod i w małych kroczak go ulepszył. Po każdym kroczku zrób commit i wyjaśnij co i dlaczego zrobiłeś.

Prototyp tego co mam na myśli dość szybko udało mi się stworzyć przy pomocy githuba.

https://github.com/dziemid/refactormycode

Napisałem  dość brzydką wersję String Calculatora , którą następnie trochę  poprawiłem .. Nie mniej wersja końcowa nie jest aż tak ciekawa jak sam proces jej tworzenia, gdzie każdy mały kroczek został udokumentowany.

Pomysł został podchwycony przez Martina, która zrefaktoryzował mój kod krok po kroku (tutaj jeden z jego kroków w raz z moim komentarzem).

Dziś wrzuciłem kolejny kod do poprawienia: Grę w życie w Javie. Kod jest napisany średnio. Miejscami jest brzydki, niektóre klasy są w ogóle niepotrzebne, inne klasy robią rzeczy, które być może powinny być gdzie indziej.

Zachęcam Cię do zrobienia „Fork”a i zrefaktoryzowania tego kodu krok po kroku. W każdym commicie napisz co i dlaczego robisz. W ten sposób razem stworzymy coding dojo rozproszone w czasie i przestrzeni :)

 

 

 

Język opcjonalnie typowany – Dart

czwartek, 20 Październik 2011

Poniższy wpis jest częścią serii opisującej moje wrażenia z konferencji GOTO Aarhus 2012. Więcej o tej konferencji. 

Na otwarcie konferencji Google przygotowało niespodziankę – nowy język programowania Dart. Dokładnie, została zaprezentowana wczesna wersja języka, nad którym ciągle trwają prace.

Jest to język opcjonalnie typowany. Możesz używać typów, ale nie musisz. Jeśli będziesz używał typów, kompilator pomoże Ci podpowiadając co dany typ potrafi lub sugerując, że chyba używasz nie poprawnego typu. Nie mniej kompilator nie będzie Cię do niczego zmuszał – to czy Twój program będzie działał czy nie, okaże się po uruchomieniu (podobnie jak w przypadku JavaScript).

Po co nowy język?

  • Dart ma być językiem, w którym „trudno” jest pisać nie wydajne programy. Google chce ułatwić swoim programistom pisanie aplikacji, które działają szybko.
  • Dart kompilowany jest do JavaScriptu, więc może działać na większości „nowoczesnych” przeglądarek. Trwają również prace nad maszyną wirtualną Darta, która będzie częścią przeglądarki Chrome. Jedna z ciekawszych opcji: „snapshot” kodu (kod może zostać prekompilowany i dostarczony do przeglądarki w postaci gotowej do wczytania do pamięci), ułatwiający bardzo szybki i wydajny start aplikacji.
  • Model konkurencji zaczerpnięty z języka Erlang. Izolaty na wzór aktorów.
  • Przemawia do ludzi z dwóch obozów (języki dynamiczne (JavaScript), języki silnie typowane(Java)
  • Być może zastąpi Javę na platformie Android?
Materiały
Język wydaje się fajny. Na następnym dojo zaproponuje, by rozwiązać w nim jakiś problem. Ciebie również zachęcam do poeksperymentowania ;)

 

 

 

 

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.