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!

sobota, 7 sierpnia 2010

Cytaty #5

Witam!

Znów bardzo krótko, ale za to z ogromnym przesłaniem. Uwielbiam czytać wypowiedzi Joela Spolsky'ego (choć na wiele trzeba patrzeć z przymrużeniem oka), tym bardziej ucieszył mnie nowy artykuł w serwisie devBlogi, tłumaczący artykuł "Prawo Nieszczelnych Abstrakcji" (w oryginale "The Law of Leaky Abstractions"). Jeden fragment z tego artykułu bardzo mi się spodobał i ucieszył, gdyż pokazuje, że moje postępowanie względem podstaw programowania jest jak najbardziej słuszne:

Prawo przeciekającej abstrakcji oznacza, że kiedykolwiek ktoś proponuje jakieś nowe super narzędzie do generowania kodu, które uczyni nas tak bardzo efektywnymi, pojawiają się ludzie, którzy mówią „najpierw naucz się jak to zrobić manualnie, dopiero później używaj tego super narzędzia oszczędzającego czas”. Narzędzia do generowania kodu, które mają na coś nakładać abstrakcję , podobnie jak wszystkie abstrakcje, przeciekają. Jedynym sposobem na kompetentne radzenie sobie z tymi przeciekami jest zrozumienie jak abstrakcje działają i - względem czego. Więc abstrakcje oszczędzają czas na pracę, ale nie oszczędzają czasu na naukę.

Pozdrawiam i do następnego razu!

piątek, 6 sierpnia 2010

Przemyślenia praktykanta #4

Witam!

Czasu ostatnio bardzo mało, ale jedna rzecz wymaga szczególnej uwagi i nie daje mi ostatnio spokoju. Jakiś czas temu głośno było o Code Review, jakie to one dobre, że każdy powinien w nich uczestniczyć etc. Można o tym poczytać np. w rewelacyjnym wpisie o Open Code Review na blogu Jakuba Nabrdalika. Niestety "nie wszyscy mają na to czas i mozliwości". Całe szczęście istnieje rozwiązanie:

15) Mini Code Review - czy żeby uczestniczyć w Code Review trzeba na to przeznaczać specjalnie czas? Czy trzeba koniecznie odciągać wszystkich od ich pracy i kazać przestawić się myślami na tą jedną godzinę, by potem wrócić rozkojarzonym do pracy? A może zamiast tego (chociażby na początek) wprowadzić to jako stałą czynność przy wytwarzaniu oprogramowania? Jakiś czas temu, gdy przesiadałem się z jednego projektu na drugi, jeden z członków zespołu developerskiego, nim zrobiłem pierwszy commit do repozytorium, poświęcił mi chwilę czasu i wyjaśnił jak mam pracować. Idea jest bardzo prosta: po każdym ważniejszym commicie (w moim przypadku po prawie każdym commicie z uwagi na małe doświadczenie :)) tworzy się wirtualny review (co zajmuje dosłownie kilkadziesiąt sekund dzięki połączeniu Atlassian FishEye + Crucible) i opisujemy w nim wykonane przez nas modyfikacje (jeżeli w opisie commitu tego nie zrobiliśmy) po czym zabieramy się za kolejne zadanie. W tym czasie osoby z naszego zespołu przeglądają nasze zmiany i oceniają lub w przypadku wątpliwości zadają pytania. Dana rewizja jest uznawana w momencie, gdy każdy z członków pomyślnie zakończy review. Ja sam działam w tym systemie zaledwie kilka dni, ale już wyniosłem z tego ogromną ilość nowej wiedzy! Co najlepsze - nie muszę odrywać nikogo od swoich zajęć jeśli chce jakąś drobną rzecz omówić - zostawiam komentarz i czekam na odpowiedź zwrotną.

Oczywiście nie mówię, że Open Code Review jest czymś złym, albo nadmiarowym - co to to nie! Po prostu widzę ile zajmuje czasu kolegom z zespołu uczenie mnie, instruowanie i tłumaczenie specyficznych zagadnień i zdaje sobie sprawę, że nie zawsze jest czas i możliwości, by usiąść i wspólnie przedyskutować dany fragment kodu na zasadzie burzy mózgów. Dzięki stałym review małych porcji kodu jestem w stanie lepiej zrozumieć system z którym pracuje i szybko wyłapywać złe praktyki lub błędy dzięki nieocenionej wiedzy bardziej doświadczonych członków zespołu :)

To tyle, czas wracać do pracy :)
Pozdrawiam i do następnego razu!