czwartek, 30 września 2010

Agile/Scrum nie tylko w projektach informatycznych

Witam!

Jako, że zacząłem właśnie ostatni (siódmy) semestr studiów inżynierskich muszę w ciągu kilku tygodni napisać pracę dyplomową. Fakt, że zacząłem własnie pracę i jeszcze jeden mini projekt na uczelni wcale tego nie ułatwia. Dlatego byłem bardzo mile zaskoczony, kiedy we wtorek przyszedłem na uczelnię i spotkałem się z moim promotorem, który oświadczył, że prace nad dyplomem będziemy prowadzić w tygodniowych sprintach! Z doświadczenia studenckiego wiem, że większości informacji, które wykładowcy przekazują nam na zajęciach zwyczajnie w życiu się nie wykorzystuje, a tu proszę, taka miła niespodzianka. Oboje z promotorem zdajemy sobie sprawę, że jest bardzo mało czasu na wykonanie pracy, ale taka organizacja bardzo to ułatwi i już widać jej pierwsze rezultaty. Dodatkowo umówiliśmy się, że w każdy poniedziałek do pewnej godziny będę wysyłać maile z krótkim sprawozdaniem co wykonałem do tej pory - coś pomiędzy codziennym standup'em, a retrospektywą na koniec sprintu. I w tym właśnie wydaje mi się, że jest ukryte piękno Agile/Scrum'a. To tak jak mówił Janusz Gorycki (z którym mam ogromną przyjemność pracować) na trójmiejskim SPIN'ie - jeśli potrzebujesz jakiejś własności/zachowania/elementu/praktyki/czegokolwiek z metodyki Scrum'a zwyczajnie adaptujesz je w swojej codziennej pracy nie przejmując się pozostałymi elementami. Dzięki temu (a zarazem przez to) do Scrum'a tak łatwo się przyzwyczaić, łatwo czerpać korzyści z korzystania z niego, ale także łatwo unikać komplikacji i problemów wynikających z jego stosowania.

To tyle krótkich refleksi na dzisiaj, czas wrócić do pracy nad projektem dyplomowym :)
Pozdrawiam i do następnego razu!

środa, 29 września 2010

Mockito i TDD - czy aby na pewno?

Witam!

Dwutygodniowe przerwy w pisaniu na blogu to jakaś klątwa Akademii :( Niemniej zważywszy na ilość pracy i obowiązków ostatnio cud, że choć tyle jestem w stanie zrobić. Temat dzisiejszego postu może trochę zmylić. Chociaż w pracy zapoznałem się z Mockito to rzecz raczej w tym, co umożliwia nam ten framework (pośrednio). Jakiś czas temu trafiłem na film ze spotkania Wrocławskiej Grupy Użytkowników Javy właśnie pt. "Mockito i TDD". O samym framework'u jest praktycznie niewiele powiedziane, pokazane nie jest praktycznie nic, ale prezentowane są bardzo mądre rady na temat pisania testów i samego podejścia do nich, toteż warto to obejrzeć:










O konstrukcji given-when-then dowiedziałem się ostatnio w trakcie pracy nad produktem z kolegą Damianem i muszę przyznać, że dzięki niej znacznie łatwiej pisze mi się testy! O wiele prościej wychwycić jest ten właściwy, pojedynczy element, który chcemy poddać testowaniu. W trakcie prezentacji wspominane są takie narzędzia testowe jak hamcrest, czy FEST-Assert. To pierwsze narzędzie znam równie krótko jak TestNG, ale w kilku przypadkach okazało się idealne, natomiast drugie bardzo mnie zaciekawiło i obiecałem sobie w ciągu najbliższych dni przyjrzeć się mu (może spisze swoje wrażenia w poście?).

A teraz aby nie przedłużać - życzę miłego oglądania :)
Pozdrawiam i do następnego razu!

poniedziałek, 13 września 2010

Mała pomoc przy pracy z GAE

Witam!

Ostatnimi czasy w celach prywatnych zająłem się małą aplikacją, która docelowo ma działać na Google App Engine. Platformie jeszcze bardzo daleko do ideału, wciąż jest ogrom rzeczy do zrobienia, ale faktem jest, że prace są prowadzone i panowie (i oczywiście panie) z Google nie ustają w swych staraniach. Przykładem mogą być dwie (wydane bardzo krótko jedna po drugiej z powodu znalezienia ważnego bug'a) aktualizacje GAE SDK: 1.3.6 i 1.3.7. Problem ze stałym rozwojem środowiska jest taki, że dosyć często następują przerwy w dostarczaniu usługi. Można śledzić bloga, można też śledzić grupę dyskusyjną, ale ja znalazłem najwygodniejsze rozwiązanie by być na bieżąco z informacjami o przerwach w działaniu GAE - kalendarz Google App Engine Scheduled Maintenance Outages. Jest wygodny, łatwy do zintegrowania z Google Calendar / iGoogle i o wiele trudniej w ten sposób zapomnieć o maintenancie.

Mam nadzieję, że ta krótka notka komuś się przyda :)
Pozdrawiam i do następnego razu!

wtorek, 31 sierpnia 2010

Przemyślenia praktykanta #5

Witam!

Znów dokładnie tydzień minął od ostatniego wpisu. Dzieje się coraz więcej, przez co czasu coraz mniej. Ale mam nadzieję, że to nie będę wciąż znacząco przeszkadzać w prowadzeniu bloga, szczególnie, że pomysłów na wpisy jest mnóstwo, tylko brakuje sił i możliwości na ich realizację (ale powoli staram się je realizować jak noworoczne postanowienia :)). A więc do rzeczy!

16) Odkładaj swoje zabawki na miejsce - podobno nazywa się to "błędem nowicjusza", ale nie sądzę, żeby był ktoś, kto tego nie czyni w swojej codziennej pracy. W większości przypadków, kiedy testuję swój (i nie tylko swój) kod, większość czasu poświęcam na znalezienie małego fragmentu kodu, w który zapomniałem jakiejś "drobnostki" - zwiększyć wartość indeksu, postawić negację w warunku logicznym etc. Takie błędy jednak są stosunkowo łatwe do wykrycia. Gorzej jest natomiast, kiedy błąd polega na nie zwolnieniu zasobów obiektu, który robi dla nas takie rzeczy jak rysowanie grafiki na podstawie zasobów systemowych lub utrwalanie danych zapisywanych do bazy. Z tym ostatnim miałem ogromną przeprawę, i od tego momentu nauczyłem się wykorzystywać sekcję finally w bloku try {} catch() :)

17) Nie zakładaj, że skoro u Ciebie działa, to u innych też zadziała - dosyć sporo czasu w trakcie praktyk poświęcam na testowanie swoich rozwiązań. Do grupy produktów, nad którą teraz pracuje, przygotowałem dosyć spore (jak na nowicjusza) i szczegółowe środowisko testowe. Kiedy skończę debugować aplikację przenoszę kod do środowiska testowego i bombarduje go różnymi dziwnymi przypadkami użycia. Taki schemat zachowania bardzo szybko wszedł mi w krew i miałem idiotyczne przekonanie, że po wyjściu ze środowiska testowego można uznać produkt za sprawny. BŁĄD!! Środowisko testowe jedynie symuluje pewne typowe, bądź mniej typowe zachowanie się produktu u klienta. Dlatego w miarę możliwości staram się, żeby ktoś, najlepiej osoba nie pracująca nad tym produktem, zobaczyła, czy u niej wszystko działa jak powinno.

18) Bądź dumny ze swojej firmy i swoich współpracowników - bardzo często podkreślałem, że czuje się szczęśliwy mogąc odbywać praktyki w Spartezie. Nie mam zamiaru nikomu słodzić, bo jak w każdej firmie są momenty fajne i przyjemne jak i takie, które chcielibyśmy, żeby nie miały miejsca. U nas jest tak, że tych pierwszych jest ponad 90%, dlatego z ogromną przyjemnością przychodzę codziennie do biura i zmagam się z coraz trudniejszymi problemami. Każdego ranka w drodze z domu na kolejkę i potem z kolejki do biura zastanawiam się z kim dzisiaj odbędę ciekawą rozmowę. Dodatkowym bodźcem jest fakt, że są to osoby, które są bardzo aktywne także poza firmą, stymulując środowisko. Czytam ich posty na różnorakich blogach, oglądam filmy z prezentacji, chodzę na ich prelekcje etc. i nie mogę się nadziwić, że Ci ludzie mają siłę i chęć codziennie odpowiadać na moje żenujące, zdecydowanie nie na ich poziomie pytania bez najmniejszego grymasu czy znużenia. To bardzo stymuluje mnie do pracy, coraz cięższej pracy, żeby któregoś dnia osiągnąć to co oni, a może nawet więcej :)

19) Dzień spędzony całkowicie na integracji jest więcej wart niż tydzień siedzenia w biurze - w zeszłym tygodniu, w poniedziałek, firma Spartez zorganizował coroczny wypad integracyjny. W tym roku wybór padł na spływ kajakami po rzece Radunia i ognisto z kiełbaskami i zimnym piwkiem. To, że jestem w zespole niespełna dwa miesiące nie miało najmniejszego znaczenia i dzięki temu po pierwsze poznałem ludzi, z którymi codziennie spędzam po 8h w jednym pokoju i zdałem sobie (ku mojej ogromnej radości) sprawę z faktu, że z każdym z tych ludzi mam temat, na który mogę porozmawiać i nie musi to być temat związany w żadnej mierze z IT, a po drugie spędziłem jeden z najlepszych dni w swojej krótkiej karierze w miłym towarzystwie przez cały czas się uśmiechając :) Poniżej zamieszczam album zdjęć ze spływu (zdjęcia robione i udostępnione przez kolegę Krystiana - dziękuję :)).


Na dzisiaj wystarczy :) Czas iść spać, żeby wyspanym i uśmiechniętym jutro znów zjawić się w biurze :)
Pozdrawiam i do następnego razu!

wtorek, 24 sierpnia 2010

They call me a Dragon Slayer!

Witam!

Dzisiejszy dzień był bardzo pracowity i pełen wyzwań. Tym bardziej po przyjściu do domu ucieszyłem się na widok paczki od amerykańskiego nadawcy - oto przyszła długo oczekiwana koszulka z firmy Atlassian - Dragon Slayer!



Dragon Slayer jest 8-etapowym cyklem wprowadzającym użytkownika w świat produktów firmy Atlassian, uczącym podstaw ich obsługi jak i integracji w jedną, dużą, komunikującą się całość. Po zakończeniu kursu można wysłać zgłoszenie wraz ze zrzutami ekranu pokazującymi efekt swojej pracy. Po kilku tygodniach (w moim przypadku czterech) dostaje się darmową koszulkę promocyjną :)

Z uśmiechem na ustach wracam teraz do pracy :)
Do zobaczenia już bardzo niedługo!

środa, 18 sierpnia 2010

Problemy z filtrowaniem w Maven'ie

Witam!

Ten wpis ma bardziej charakter przypominajki dla mnie, ale jestem pewien, że komuś też się to przyda. Od jakiegoś czasu w kilku projektach, w trakcie tworzenia plików projektu Eclipse z czystego projektu Mavena pojawiał mi się taki błąd:

[INFO] Resource directory's path matches an existing source directory. Resources will be merged with the source directory src/main/resources
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Request to merge when 'filtering' is not identical. Original=resource src/main/resources: output=target/classes, include=[atlassian-plugin.xml], exclude=[**/*.java], test=false, filtering=true,
merging with=resource src/main/resources: output=target/classes, include=[], exclude=[atlassian-plugin.xml|**/*.java], test=false, filtering=false
[INFO] ------------------------------------------------------------------------


Pojawia się on wtedy, kiedy dany zbiór zasobów filtrujemy więcej niż jeden raz (działanie zdefiniowanie w pliku POM.xml) i wywołujemy komendę:

mvn eclipse:eclipse

Co się okazuje, najnowsza wersja pluginu Mavena do generowania plików projektu Eclipse (2.7) nie radzi sobie z tym problemem w przeciwieństwie do swojej poprzedniczki - wersji 2.6. Aby temu zaradzić, zamiast mvn eclipse:eclipse wywołujemy komendę:

mvn org.apache.maven.plugins:maven-eclipse-plugin:2.6:eclipse

Mam nadzieję, że komuś się to przyda :)
Pozdrawiam i do następnego razu!

sobota, 14 sierpnia 2010

Code Review for Teams Too Busy to Review Code

Witam.

Pamiętacie wpis sprzed tygodnia o Mini Code Review? Od tamtej pory, kiedy przelałem swoje myśli w post na blogu, coraz więcej zacząłem o tym myśleć i coraz więcej dostrzegać korzyści z tego płynących. Przez ostatni tydzień mierzyłem się z pewnym zagadnieniem, które jest bardzo słabo (a praktycznie wcale) nieudokumentowane i bardzo często Google kierowało mnie na stronę Atlassian Summit 2010. Pomijając fakt, że zakochałem się od pierwszego wejrzenia w takich technologiach Atlassianowych jak JIRA, FishEye, a najbardziej Crucible, a w trakcie praktyk pracuję z produktami firmy Atlassian, postanowiłem trochę więcej dowiedzieć się na ich temat. Ponieważ w wielu przypadkach wolę o czymś posłuchać lub to obejrzeć niż o tym przeczytać, postanowiłem obejrzeć film na temat Code Review. Nie będę zdradzać co bardzo mi się spodobało w tej prezentacji, ale wydaje mi się, że po obejrzeniu go większość z Was będzie miała podobne wrażenia :)


Zachęcam do komentowania i do zobaczenia w następnym poście!