piątek, 22 czerwca 2012

Poszukiwany, Poszukiwana

Dotychczas rośliśmy równomiernie, acz powoli. Niedawno minęły 3 lata od kiedy zaczęliśmy przygodę o nazwie Pragmatists. W tym czasie rozwijaliśmy projekty, zajmowaliśmy się szkoleniami z procesów i praktyk agile'owych, pomagaliśmy innym zespołom poprzez coaching.

Dla siebie opracowaliśmy zestaw praktyk, które pozwalają nam tworzyć oprogramowanie wysokiej jakości oraz wypracowaliśmy sposób prowadzenia firmy i zespołu tak, żeby z przyjemnością i efektywnie spędzać razem czas. Dzięki temu mamy trochę nowych projektów. Dlatego chcemy poszerzyć nasz zespół o osoby, które są gotowe razem z nami tworzyć Pragmatists.

Jeśli myślisz, że odpowiadałby Ci nasz sposób pracy (szczegóły na naszej stronie), czuj się zapraszon[a|y].

Chcemy pracować z osobami, które:
- lubią się uczyć i pomagają innym się rozwijać
- lubią bliską współpracę z ludźmi

Musisz także:
- dobrze mówić po angielsku
- mieć solidną wiedza javową, okołojavową, no i ogólnie programistyczną

Chcesz poznać szczegóły albo podesłać CV? Pisz na contact na pragmatists.pl albo bezpośrednio do mnie na pawel.lipinski na pragmatists.pl

niedziela, 12 czerwca 2011

Piosenka o refaktoryzacji

Parę osób (no większe parę ;-)) prosiło mnie o udostępnienie mojej tfu-rczości Konfiturowej na YT, co niniejszym uczyniłem. Have Fun!

środa, 18 maja 2011

Przyjęta propozycja na Software Craftsmanship 2011

Mnie w tym roku na Confiturze nie będzie, ale zazdroszcząc Pawłowi i Piotrowi zgłosiłem swoją sesję na inną konferencję. I została przyjęta! Będę więc godnie reprezentować Pragmatists na Wyspach.

Sesja będzie polegać na pisaniu kodu przy zachowaniu zasad ekstremalnego projektowania obiektowego. Pisał o nich niegdyś Paweł na swoim blogu.

Opis i link do wideo na stronie ze szczegółami wszystkich sesji SC 2011.

Jeśli chcecie się dowiedzieć więcej o samej konferencji, zapraszam na oficjalną stronę Software Craftsmanship 2011.

Propozycje na Confiturę przyjęte

Zarówno moja propozycja prezentacji na temat zaawansowanych refaktoryzacji, jak i temat Piotrka Przybylaka o korzystaniu z mózgownicy zostały przyjęte. Teraz Wam pozostaje się na nich pojawić, a nam dobrze je przygotować ;-)

poniedziałek, 16 maja 2011

JUnitParams

Niedawno dopisałem do Tumblera możliwość definiowania scenariuszy parametryzowanych. Chodzi o to, żeby móc zdefiniować parę zestawów parametrów scenariusza i mieć ten sam jeden scenariusz wykonany dla wszystkich zestawów, weryfikując w ten sposób jego poprawność dla różnych danych. Ale jako, że nie wszyscy chcą używać Tumblera (i nie zawsze jest sens), przepisałem tę funkcjonalność do czystego JUnit'a. Po co? Głównie dlatego, że testy parametryzowane w JUnit to porażka. Z runnerem Parameterized Testy są wg. mnie mniej czytelne, tworzy się dużo klas, generalnie kiszka. Na dodatek do Parameterized są też teorie, które miały rozwiązać parę problemów, ale chyba nikt ich nie używa.
Ostatnio jednak mieliśmy w projekcie sytuację, w której testy parametryzowane byłyby wygodne... gdyby były wygodne. Więc wyciągnąłem ten kawałek Tumbler'a na zewnątrz i tak powstał JUnitParams. Teraz testy parametryzowane w JUnit są dużo przyjemniejsze.

Jak to działa?
1. Trzeba zdefiniować runner (JUnitParamsRunner) -  bo JUnit nie umie wykonać tego samego testu parę razy, a przecież o to nam chodzi.
2. Stworzyć metodę testową z parametrami metody testowej oraz zadnotować ją za pomocą @Parameters podając parametry bezpośrednio w adnotacji, lub podając klasę dostarczającą te wartości z zewnątrz. Jeśli chcemy podać parametry bezpośrednio, to podajemy je jako tablicę String'ów, której każdy element jest jednym zestawem parametrów:
@Parameters({"1, Jaś, true", "2, Andżelika, false" })
Tak podane parametry są następnie parsowane i rzutowane na odpowiednie podstawowe typy javowe.
Jeśli zaś zestawów parametrów ma być więcej, lub chcemy je pobrać dynamicznie np. z pliku bądź bazy, możemy podać klasę dostarczającą wartości parametrów:
@Parameters(source=NamesParamsProvider.class)
Co do tej klasy nie ma żadnych wymagań poza posiadaniem przynajmniej jednej publicznej statycznej bezparametrowej metody zaczynającej się od provide. Wszystkie takie metody są uruchamiane, ich wyniki zbierane i dostarczane do metody testowej.
Można też przekazywać parametry bez zewnętrznej klasy - podając metodę testu zwracającą dane w adnotacji:
@Parameters(method="samplePeople")
3. Już. Żadnych konstruktorów, pól w klasie testowej, czy innych zbędnych dodatków.

Przykładowy test z parametrami wygląda np. tak:

@RunWith(JUnitParamsRunner.class)
public class PersonTest {

  @Test
  @Parameters(method = "adultValues")
  public void isAdult(int age, boolean valid) {
    assertThat(new Person(age).isAdult(), is(valid));
  }

  private Object[] adultValues() {
    return $(
      $(17, false),
      $(22, true)
    );
  }
}

Więcej przykładów na stronie projektu.

niedziela, 15 maja 2011

Nasze propozycje na Confiturę

Confitura już dość blisko. W tym roku z naszego zespołu wyszły dwie propozycje tematów. Pierwsza Piotra Przybylaka "Pisz po pijaku, przeglądaj na trzeźwo". To jedna z tych, których sam tytuł niewiele mówi, więc oto jej abstrakt:

Jakie jest najważniejsze narzędzie programisty?
Twój mózg.
Czy umiesz się nim efektywnie posługiwać?
Czy wiesz jakie kryje "bugi"?
Czy działa racjonalnie?
Ani w szkole ani na studiach nikt nie uczy nas jak posługiwać się najważniejszym narzędziem w naszej pracy - nie uczymy się jak się uczyć. Warto to zmienić, wiec postaram się przedstawić skróconą instrukcje obsługi Twojego mózgu.
Opowiem:
- O tym jak ludzki mózg przetwarza problemy i tworzy ich rozwiązania.
- Jak efektywnie połączyć w swojej pracy wykorzystanie przetwarzania świadomego i nieświadomego, racjonalnego i nieracjonalnego.
- Jak kierować swoim rozwójem. Czyli co bracia Dreyfus odkryli badając ograniczenia sztucznej inteligencji, a co japońscy mistrzowie sztuk walki wiedzą od wieków.
- Jak ujawniają się zaszyte w nim bugi: "Legacy brain".

Druga jest moja (Pawła Lipińskiego). Jej tytuł to "Re-fuck-toryzacja czyli sprowadzanie sp****go kodu na właściwe tory". Krótki opis:

Design w twoim projekcie ssie? Kod strukturą przypomina wielki parujący krowi placek? Ta prezentacja jest dla Ciebie. Przypomnisz sobie do czego służy menu Refactor w Twoim IDE, zobaczysz jak dopisywać testy do tego czegoś co nie wiadomo jak działa i jak przekształcać kod w kierunku wzorców projektowych. Przyjdź i oszczędź swoim kolegom z zespołu paru WTF przy przeglądaniu Twojego kodu!

Tym razem Piotr będzie więc miał coś z tematów miękkich, ja kodując na ekranie opowiem o stosowaniu refaktoryzacji i pokażę jak wyglądają refaktoryzacje na wyższym poziomie,  czyli coś czego nawet najmądrzejsze IDE samo nie wymyśli.
Jako, że w tym roku kapituła Confitury dała prawo głosu na tematy uczestnikom, jeśli chcecie nas posłuchać głosujcie w tej ankiecie.