poniedziałek, 27 grudnia 2010

Cytaty #8

Witam!

Nie wiem dlaczego, ale mam ostatnio nieodpartą ochotę pisać jak najwięcej postów na blogu :) Tym razem chciałbym przedstawić trzy zasłyszane hasła, które głęboko utkwiły mi w pamięci, oraz które dały mi wiele do myślenia.

Pierwszy z nich pochodzi z jednego z moich ulubionych seriali - Chorych Doktorów (ang. Scrubs). W jednej ze scen Bob Kelso mówi do swojej pacjentki (a także do przysłuchującego się Turk'a):
"Nic, co jest warte posiadania, nie przychodzi łatwo (...)"
Jakby tego było mało, potwierdza to niejako Rendy Pausch, którego książkę - Ostatni Wykład - w ostatnim czasie przeczytałem już po raz trzeci od deski do deski. Są w tej książce (a także na wideo z jego faktycznego ostatniego wykładu) pewne bardzo słuszne słowa:
"Mury istnieją po to, by powstrzymywać ludzi, którzy nie pragną czegoś dostatecznie mocno"
Na sam koniec przytoczę słowa Dona Brown'a z firmy Atlassian, który to w trakcie prezentacji pt. "Functional and Integration Testing for the Lazy" na AtlasCamp 2010 powiedział:
"As we start any good story, every story begins in Maven"
Nie trzeba chyba dodawać, że Don nie jest miłośnikiem skomplikowania, jakie niesie ze sobą Maven, gdy używa się go w większych projektach? :) Prawda jest taka, że Maven jest cudowny, umożliwia i ułatwia wiele rzeczy, lecz każde ulepszenie przynosi tyle samo, jeśli nie więcej, problemów do rozwiązania. W moim przypadku, w ostatnim okresie, znaczną część czasu poświęcam na poprawianie konfiguracji Mavena zamiast zajmować się implementacją nowych funkcji w projekcie, co potrafi naprawdę mocno zniechęcić do tego narzędzia.

Pozdrawiam i do następnego razu!

niedziela, 26 grudnia 2010

Agile Central Europe 2010

Witam!

Święta to idealny czas na nadrobienie zaległości, które nie wymagają zbyt wiele zachodu. Ponieważ ostatnie kilka tygodni było naprawdę zwariowane, nie miałem tak naprawdę czasu przejrzeć ostatnich numerów JAVA exPress, czy też Software Developer's Journal, lub też być na bieżąco z ciekawymi prezentacjami na InfoQ. Całą sytuację pogorszył jeszcze fakt startu nowej inicjatywy kolegi z pracy, Damiana Nowaka - wPolsce.it. Jest to portal, na łamach którego publikowane mają być docelowo informacje o wszystkich konferencjach informatycznych w Polsce. Dzięki tej inicjatywie dowiedziałem się o konferencji, która miała miejsce w tym roku - Agile Central Europe 2010 w Krakowie. Piszę o tym, ponieważ przeglądając stronę konferencji natrafiłem na zapis wideo prezentacji Roberta Dempsey'a o ciekawym tytule "Distributed Agile in a Multicultural World". Od kiedy trafiłem do swojej pierwszej prawdziwej pracy informatycznej około 4 lata temu pracowałem zdalnie, w domu. Nie było biura jako takiego, był tylko sklep, dla którego pracowałem, lub od czasu do czasu mieszkanie właścicielki firmy oraz jej partnera, gdzie odbywały się sesje planowania. Już po kilku tygodniach pracy tam miałem okazję załatwiać sprawę z ludźmi zza granicy, co wpierw napawało mnie strachem (do tej pory nigdy nie opuściłem granic naszego wspaniałego ojczystego kraju), a także ekscytacją w różnej postaci. Już wtedy, te 4 lata temu, postanowiłem dojść w swojej karierze zawodowej do miejsca, w której będę pracował z ludźmi nie tylko z innego kraju, ale także innego kontynentu. Nie tak dawno temu, kiedy dostałem propozycję pracy w Spartezie (a jeśli mam być szczery już w trakcie odbywania tam praktyk studenckich) marzenie to powróciło ze zdwojoną siłą. Wraz z tym marzeniem przyszło przeświadczenie, że tak naprawdę nie jestem w żaden sposób przygotowany do takiej pracy i nie mam tu na myśli tylko moich zdolności programistycznych. Idąc tym tropem postanowiłem wolną chwilę w te święta spędzić na obejrzeniu prezentacji Roberta i czas na to poświęcony nie był ani trochę zmarnowanym. Prezentacja jest bardzo ciekawa i pomogła otworzyć mi oczy na tak wiele aspektów zdalnej pracy interkontynentalnej, że tak naprawdę mam teraz więcej pytań i wątpliwości niż wcześniej. Sądzę jednak, że jest to dobry objaw, gdyż pokazuje, że mi zależy. Ale żeby nie przedłużać, oto wspomniana przeze mnie prezentacja:

Robert Dempsey - Distributed Agile in a Multicultural World from Krakow Tech Conferences on Vimeo.

Niestety filmik nie jest w najlepszej jakości, nie widać slajdów przez większość czasu - jednym słowem - Parleys to to nie jest ;) Przeglądając kanał na Vimeo, na którym umieszczono prezentację natrafiłem jeszcze na kilka zapowiadających się ciekawie prezentacji. "Refactoring Test Code" Piotra Jagielskiego okazał się zacząć bardzo dobrze, lecz nie dane mi było dotrwanie choćby do 1/3 prezentacji - prelegent omawiał wyświetlany na rzutniku kod, który był całkowicie nieczytelny dla widza. Maria Diaconu wraz z Alexandrem Bolboacă wygłosili prezentację na temat "Software as a craft - an introduction to the Software Craftsmanship movement" - temat, który dzięki Sławomirowi Sobótce jest mi znany o tyle, że jestem świadom jego istnienia i chętnie dowiaduje się czegoś na ten temat przy każdej możliwej okazji. Niestety prezentacja nie była ciekawa, a to za sprawą ciężkiego dla ucha angielskiego oraz małej ilości przekazanych treści.

Święta przed chwilą się skończyły, tak więc czas przygotować się do powrotu do pracy, na dziś to tyle.
Pozdrawiam i do następnego razu!

sobota, 25 grudnia 2010

Co nowego w IntelliJ IDEA 10

Witam!

Dwa tygodnie temu wróciłem po długim (5-tygodniowym) urlopie do pracy. Pierwsze co zwróciło moją uwagę to aktualizacja obecnie używanego przeze mnie IDE - IntelliJ IDEA - do wersji 10. Od dłuższego czasu, jeszcze przed pójściem na urlop, było dosyć głośno na temat nowej wersji naszego ulubionego edytora. Największy nacisk miał zostać położony na wydajność aplikacji, ale nie miało to być jedyne udostkonalenie, które miała wnieść najnowsza wersja. Poniżej prezentuje liste rzeczy, które najbardziej spodobały mi się w IDEA 10:
  1. Poprawiona wydajność - na stronie z informacjami o nowościach w wersji 10 firma JetBrains informuje, że nowa IDEA uruchamia się w czasie dwukrotnie szybszym niż poprzednia wersja, podobnie jak indeksowanie projektu. Liczby trochę przesadzone, ale 30-35% szybsze działanie, które osobiście odnotowałem od samego początku pracy z nową wersją edytora robi naprawdę duże wrażenie.
  2. Odczepiane okna - to opcja, której bardzo brakowało mi po przesiadce z Eclipsa na IntelliJ IDEA. W nowej wersji brak ten został uzupełniony i możemy ustawiać okna edytora dowolnie, wedle uznania. Jest to bardzo ważne, kiedy pracuje się na dwóch monitorach. Mała rzecz, a cieszy :) Wiele osób bardzo narzekało, że w jednym oknie nie da się zmieniać w prosty sposób kolejności zakładek - teraz jest to równie proste jak w innych znanych IDE. Poniżej filmik prezentujący nową opcję:
  1. Zakładki - to ciekawy sposób na zaznaczenie istotnego w danym momencie fragmentu kodu. Dzięki temu nie ma konieczności przeglądania od nowa całego kodu, aby znaleźć interesujący nas fragment. Poniżej prezentacja nowej funkcji:
  1. Instant Autocompletion - polega na podpowiadaniu składni bez konieczności ciągłego wciskania kombinacji Ctrl + Space. Choć pokazano, że przyspiesza to prace przy pisaniu kodu (szczególne wrażenie zrobiło na mnie podpowiadanie składni XPath) to znając życie bardzo dużo osób zrezygnuje z tej funkcji całkowicie po relatywnie krótkim czasie. Mi na razie się podoba i jest wygodne, więc póki się nie zirytuje, póty zostaje :)
  1. Integracja z Apache Maven - obsługa Mavena w IntelliJ IDEA jest tzw. out-of-the-box, czyli nie potrzeba żadnych dodatkowych paczek, aby z niego korzystać. W nowej odsłonie edytora dodano indeksowanie zdalnych repozytoriów, pomoc przy refaktoryzacji pliku POM, etc.

  1. Productivity Guide - to dodatek trochę dla zabawy, choć w połączeniu z rozszerzeniem Key Promoter może być bardzo pomocne. Idea jest bardzo prosta - IDEA zlicza ilość wykorzystania ułatwień, jakie dostarcza edytor i zestawia je w przejrzysty sposób. W ten sposób możemy łatwo dowiedzieć się o nowych skrótach klawiszowych, których jeszcze nie znaliśmy, a mogą nam się bardzo przydać. Dodatkowo każde z udoskonaleń jest opisane wraz ze skrótem klawiszowym oraz stosownym zrzutem ekranu.



Czas powiedzieć co mi się nie podoba w nowej odsłonie IntelliJ IDEA:
  1. Sposób tworzenia branchy/tagów w Subversion - nie udało mi się jeszcze zrobić branchu w repozytorium SVN'a przy pomocy IDEA'i w sposób zadawalający. W Eclipse wystarczyło wskazać folder, do którego chce przekopiować katalogi z głowy trunk'a lub wskazanego innego folderu w repo, natomiast IDEA dodaje do przygotowanej przeze mnie lokalizacji folder o nazwie, którą pobiera ze źródłowego URL'a i dopiero tam kopiuje pliki - bardzo niewygodne.
  2. Nie wszystkie nowe opcje działają w Community Edition - przykładowo nowe możliwości w obsłudze Maven'a nie są dostępne w wersji CE, co jest bardzo rozczarowujące.
  3. Problem z pluginami - po aktualizacji z wersji 9 do 10.0 okazało się, że muszę instalować wszystkie rozszerzenia na nowo. Dziwne, bo sądziłem, że skoro wskazałem lokalizację poprzedniej wersji, gdzie znajdowały się pliki konfiguracyjne, IDEA sama się zorientuje, że trzeba trochę oprogramowania doinstalować...
W momencie pisania tego postu IDEA poinformowała mnie o dostępności nowej wersji, 10.01 build 99.32 (IDEA 10 to build 99.18), w której wprowadzono liczne poprawki. Taki stan rzeczy bardzo cieszy. Widać, że oprogramowanie się rozwija i to w bardzo dobrą stronę, czas więc zacząć zbierać na wersję Ultimate Edition :)

Z miłych zaskoczeń przy aktualizacji oprogramowania: od niedługiego czasu jestem szczęśliwym posiadaczem nowego laptopa - HP Pavilion dv7-3130ew. Zainstalowana w nim karta WiFi jest firmy Broadcom, a z tego co wcześniej się orientowałem, jej instalacja pod Ubuntu bywa problematyczna. Jakież wielkie było moje zaskoczenie, gdy po pierwszym uruchomieniu Ubuntu 10.10 system zapytał mnie, czy nie chce zainstalować sterownika karty graficznej, karty WiFi oraz tunera cyfrowego DVR. Zgodziłem się i od tej pory nie mam z tym najmniejszych problemów - doskonały wzór dla twórców oprogramowania, co znaczy program user-friendly :)

To tyle na ten moment, czas wracać do świątecznego stołu i cieszyć się chwilami wytchnienia spędzonymi z rodziną :)

Pozdrawiam i życzę wszystkim wesołych świąt!!!

poniedziałek, 6 grudnia 2010

Cytaty #7

Witam!

Dzisiaj usłyszałem bardzo mądre słowa człowieka, który żył dawno temu, lecz jego słowa są aktualne także dzisiaj i jestem pewien, że będą za kolejnych 100, 200, czy 500 lat. Mowa tu o Williamie Faulkner'ze. Był to amerykański powieściopisarz, poeta, laureat Nagrody Nobla w dziedzinie literatury. A oto co powiedział w 1958r. Jean Stein'owi:
Always dream and shoot higher than you know you can do. Don't bother just to be better than your contemporaries or predecessors. Try to be better than yourself (...).
I chociaż Faulkner mówił wtedy o pisarzach, to jednak nie ma chyba branży, w której słowa te nie miały by swojej racji. Bardzo często pracujemy lub uczymy się w towarzystwie ludzi z dużym doświadczeniem lub sporym talentem i notorycznie próbujemy być lepsi od nich. Niestety bardzo często okazuje się, że jest to zgubna motywacja - osoby te także stają się coraz lepsze, coraz trudniej być od nich lepszym. Za to samo bycie jutro lepszym od siebie samego, niż jest się dzisiaj, jest doskonałą motywacją dającą wciąż nowe, coraz lepsze wyniki.

Natchniony tą myślą wracam do pracy :)
Pozdrawiam i do następnego razu!

sobota, 4 grudnia 2010

Nowy blog o Tapestry

Witam serdecznie!

Pierwszy projekt z użyciem frameworku Spring 3 za mną, teraz prace skoncentrowane na zapoznawaniu się z językiem Jython i pisaniu pracy inżynierskiej. Chociaż ostatnio coraz częściej spotykam się z opinią, że znajomość, choćby podstawowa, Springa to podstawa, to uważam używanie go do małych aplikacji za strzelanie do muchy z armaty. Znacznie pozytywniejsze wrażenie odniosłem odnośnie frameworka Tapestry (w wersji 5.2) po prezentacji Michała Grucy na spotkaniu Trójmiasto Java User Group pt. "Przegląd możliwości szkieletu aplikacyjnego Tapestry 5". Od tamtego momentu czekam z niecierpliwością na możliwość poznania w praktyce podstaw tego cudeńka. Ponieważ przez najbliższych kilka tygodni nie zapowiada się na to, żebym miał ku temu możliwość pocieszam się wpisami na blogu Michała, które wreszcie zgodził się upublicznić. I tak oto mam ogromną przyjemność zaprezentować "Reliable IT Solutions" - polski blog o podstawach programowania z użyciem Tapestry dla początkujących i nie tylko. A o to co sam autor o nim pisze i jak definiuje cel swojego młodego przedsięwzięcia:
Jestem jeno skromnym programistą, który stara się uczynić świat lepszym, poprzez promowanie dobrych nawyków i lepszych technologii. Mam nadzieję, że poprzez tego bloga, uda mi się dotrzeć do kilku osób i uczynić ich życie lepszym, by nie popełniały tych samych błędów, które ja musiałem popełnić.
Pozdrawiam i zachęcam do czytania wpisów Michała!

wtorek, 9 listopada 2010

Dlaczego lubię Jersey'a

Witam!

Jest wtorkowy wieczór a ja zamiast siedzieć gdzieś z kolegami w PUB'ie, lub z dziewczyną w kinie, spędzam swój "wolny czas" pisząc kod do projektu grupowego, którego termin oddania zbliża się nieubłaganie. To dlaczego jestem taki uśmiechnięty? Otóż przyszedł ten moment, kiedy nareszcie trzeba zbudować RESTful Web Service. Dlaczego mnie to cieszy? Bo pisanie RESTowych usług jest bardzo proste i przyjemne, a to za sprawą frameworka Jersey :) Nie będę się rozwodził przesadnie nad tym dlaczego tak go lubię, gdyż pisać na ten temat można naprawdę długo i wiele. Wystarczę, że przytoczę artykuł, na który natknąłem się w czasie szukania informacji o wstrzykiwaniu obiektu sesji do RESTowej metody:
This framework looks like it will have long legs in the Java community.
Osobiście zgadzam się całkowicie z tą opinią. Wiele jest narzędzi do budowania RESTful Web Services, ale nie spotkałem jeszcze nikogo, kto dla osoby początkującej nie zalecił właśnie frameworka Jersey. Jak się później okazuje jest to miłość od pierwszego wejrzenia i wielu ludzi pozostaje przy tym rozwiązaniu, a to mówi samo za siebie :)

Pozdrawiam i do następnego razu!

piątek, 5 listopada 2010

Cytaty #6

Witam!

Sporo czasu minęło od ostatniego wpisu z cytatem (od zwykłego wpisu zresztą też). Jakiś czas temu przeglądałem materiały z Atlassian TV i natrafiłem na ciekawy materiał jednego z developerów firmy Atlassian o tym jak sprawna automatyzacja pozwoliła ułatwić i przyspieszyć prace nad projektem. Podsumowując swoją opowieść George Barnett powiedział:
Automation is key.
Ta prosta sentencja dała mi wiele do myślenia. W swojej nowej pracy jako Junior Software Developer bardzo często z braku wiedzy, doświadczenia jak i znajomości technologii bardzo często wiele rzeczy robię "na piechotę". Podobnie jest z projektami na uczelni, a także własnymi mini-projektami. Pierwsze objawienie przyszło w momencie rozpoczęcia pierwszego poważniejszego projektu w ramach praktyk. Później w trakcie pracy z kolegą ze studiów nad projektem grupowym doszedłem do wniosku, że nawet najprostsza automatyzacja może bardzo ułatwić nam pracę (zwykłe przerobienie projektu, by można było nad nim pracować za pomocą Apache Maven uczyniła dosłownie cuda). Następnym krokiem w drodze ku oświeceniu był artykuł na devBlogach pt. "Jak efektywnie realizować zadania, kiedy jesteś tylko szeregowym programistą", który zaprowadził mnie do artykułu Joela Spolsky'ego "The Joel Test: 12 Steps to Better Code". Te wszystkie rzeczy uświadomiły mi, że nie tylko poznawanie nowych frameworków, wzorców projektowych, praktyk poprawiających efektywność pracy programistycznej etc. sprawiają, że moja praca może być lepsza. Dlatego w tym tygodniu wraz z moimi wykładowcami postanowiliśmy w formie testu przeprowadzić inspekcję kodu w sposób zautomatyzowany - kilka wybranych grup będzie poddawać rewizji kod innych grup w standardowy sposób - przy pomocy kodu wydrukowanego na kartkach, a pozostali będą używać do tego tandemu Atlassian FishEye + Crucible. Jakie będą tego wyniki? Napiszę już niedługo :)

Tym czasem pora wrócić do pisania kodu.
Pozdrawiam i do następnego razu!

czwartek, 21 października 2010

O dokumentacji słów kilka

Witam serdecznie!

Przez natłok pracy w ostatnim czasie nie mam możliwości być całkowicie na bieżąco z nowinkami ze świata informatyki (i nie tylko), przez co mam pewne zaległości na takich serwisach jak devBlogi, czy infoQ. Próbując trochę nadrobić zaległości z pierwszego serwisu trafiłem na bardzo pocieszający wpis - "Ostateczne programistyczne kata", które jest tłumaczeniem artykułu Jeffa Artwood'a. Dlaczego pocieszający? Ponieważ w bardzo bezpośredni sposób uzasadnia sensowność i starania wkładane w prowadzenie tego bloga, oto cytat:
Prowadź bloga. Ja sam zacząłem pisać tego bloga na początku 2004 roku właśnie jako formę ćwiczenia. Zaczynając skromnie, później okazało się, że jest to jedna z najbardziej znaczących rzeczy, które zrobiłem w swojej zawodowej karierze. Ty również powinieneś prowadzić bloga.
Kolejne "objawienie" przyszło w momencie czytania artykułu "Pisanie dobrej dokumentacji: co napisać". Jakiś czas temu wspominałem, że w trakcie praktyk jednym z moich obowiązków było utrzymywanie i rozwijanie dokumentacji projektu. Dodajmy do tego jeszcze artykuł "Pisanie dobrej dokumentacji: styl" i okazuje się, że tak naprawdę niewiele wiem o pisaniu dokumentacji! Pokazuje to także jak obszerną (o wiele obszerniejszą niż sądziłem kilka miesięcy temu!) dziedziną jest informatyka :)

Na dzisiaj to tyle blogowania, czas zabrać się za pracę inżynierską :)
Pozdrawiam i do następnego razu!

niedziela, 17 października 2010

Przemyślenia praktykanta #6 - podsumowanie

Witam serdecznie!

Ponad trzy tygodnie po terminie, ale jak mówi polskie przysłowie "lepiej późno niż wcale" ;) Długo zastanawiałem się nad tym co mógłbym napisać w podsumowaniu praktyk, kiedy większość przemyśleń umieściłem w poprzednich wpisach.

20) Agile/Scrum jest idealny dla początkujących programistów - bałem się bardzo ilości dokumentacji, planów projektów itp. na początku pracy z ekipą ze Spartezu. Bałem się z dwóch przyczyn: tego, że będą zbyt zaawansowane technicznie oraz czasu, który będę musiał na nią poświęcić przez co nie zdążę zrobić nic znaczącego w trakcie praktyk. Z tymi obawami związany jest kolejny punkt...

21) Praktyki 3-miesięczne to strzał w dziesiątkę - moje praktyki trwały dokładnie 60 dni i od samego początku czułem, że wydłużenie standardowego czasu (20 dni) będzie strzałem w dziesiątkę. Praktyki są tak bogate w nową wiedzę i doświadczenia, że grzechem byłoby z tej możliwości nie skorzystać maksymalnie jak się da. Dzięki wydłużonemu czasowi miałem możliwość nadrobienia wielu zaległości w postawach znajomości Javy ale i zwykłej wiedzy informatycznej (a także trochę psychologii itp. :)) oraz spokojnie popracować nad konkretnym projektem. Jednym z rezultatów mojej pracy był plugin do Atlassian JIRA oraz pluginu GreenHopper, który miał swoją premierę na Atlassian Plugin Exchange prawie miesiąc temu!

22) Praca informatyka to ciągła nauka - ale nie mam tutaj na myśli tylko nauki nowego języka, czy tez technologii. Praktycznie każdego dnia uczyłem się pokory oraz poznawałem granice swoich umiejętności, by za chwile je przekraczać i stawać się coraz lepszy. Praktyki to specyficzny okres, gdyż granic takich jest bardzo dużo, mało jeszcze tak naprawdę wie się o programowaniu i pracy w prawdziwym zespole. Krzywa uczenia się w trakcie praktyk jeśli ma się szczęście pracować w zespole skłonnym do pomocy niedoświadczonemu programiście rośnie w zawrotnym tempie. Jeszcze kilka tygodni temu nie podejrzewałbym siebie o możliwości tak szybkiej nauki :)

23) Praktyki wakacyjne mogą (i są!) świetną zabawą - kiedy pracuje się w zespole takim, w jakim ja miałem przyjemność przychodzenie do biura staje się czystą przyjemnością, każdy dzień zaskakuje nas czymś nowym, interesującym, ale także jest kolejną okazją do dobrej zabawy. W pokoju w którym siedziałem w drugiej części praktyk (razem z siedmioma innymi osobami) aż wrzał od śmiechu, dowcipów etc. Oczywiście, ważny jest umiar i zachowanie proporcji praca-zabawa, lecz oczywistym jest także, że "nikt" nie wysiedzi 8 godzin non-stop kodując i mając z tego dużą przyjemność (a przynajmniej ja tak nie mam), a chwile poświęcone na rozrywkę różnego rodzaju bardzo dobrze wpływają na morale zespołu oraz chęć do dalszego zmagania się z kolejnymi problemami.

Podsumowując to wszystko - praktyki uważam za bardzo udane, gdyż otworzyły mi bardzo szeroko oczy, były okazją do poznania zawodu "zza kulis" oraz były ciekawą i przyjemną formą spędzenia czasu. Co dalej? Rozpocząłem okres próbny jako Junior Software Developer i próbuję to pogodzić ze studiami (semestr pracy inżynierskiej) oraz innymi obowiązkami, na razie ze słabym skutkiem. Ale jestem wciąż dobrej myśli i jeśli wszystko pójdzie dobrze będę dalej publikować swoje przemyślenia i spostrzeżenia, tyle że tym razem jako początkujący programista, nie praktykant ;)

To wszystko na dziś, pozdrawiam i do następnego razu!

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!

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!

sobota, 31 lipca 2010

Eclipse + Aptana Studio + jQuery

Witam ponownie w ten ciepły i przyjemny wieczór :)

Dzisiaj jest dobry dzień na blogowanie :) Po spisaniu kolejnych przemyśleń z praktyk postanowiłem podzielić się kolejną rzeczą, która de facto jest z nimi związanymi, ale najpierw dwa zdania wyjaśnienia. Bardzo często spotykam się w rozmowach z developerami z opinią, że "Eclipse śmierdzi". Przykładem jest komentarz Henryka Konska pod postem o m2eclipse. Podobnie mam w pracy, gdzie pewna osoba korzystająca z NetBeans/IDEA bardzo stwierdza w ciemno "w Eclipse tego nie ma" albo "w Eclipsie to nie działa". Dlaczego tak mnie to denerwuje? Ponieważ wydaje mi się, że każdy IDE ma swoje wady i bugi, ale każdy jest też dla innego typu programisty, z innym nastawieniem do pracy. Dla mnie Eclipse jest bardzo dobry z kilku prostych przyczyn:
  • przy podstawowej pracy (moja praca najczęściej nie jest wielce skomplikowana) Eclipse w czystej postaci jest zwyczajnie szybki, to taki notatnik na sterydach
  • jeśli potrzebuję dodatkowej funkcjonalności (jak w dalszej części tego postu zostanie opisane) zwyczajnie znajduje link, wybieram komponent i instaluję (dla tych, którzy zaatakują mnie pluginem typu m2eclipse -> zobaczcie czy plugin do GAE w NetBeans 6.9 działa tak jak w Eclipse)
  • jeśli wziąć pod uwagę Eclipse, NetBeans i IntelliJ IDEA - dla początkującego Eclipse jest najprostszy - takie jest bynajmniej moje zdanie :)
Wracając do tematu postu - jQuery w Eclipse - standardowo w Eclipse JEE mamy podstawowe wsparcie dla JavaScriptu, ale dla jego biblotek (jak jQuery, Prototype itp.) nie. Bardzo dobrym zapełnieniem tej luki jest Aptana Studio. Jest to rozbudowane środowisko do tworzenia aplikacji webowych pracujące samodzielnie lub jako plugin Eclipse. W momencie moich pierwszych zabaw z AS musiałem zadowolić się konfiguracją Eclipse Galileo (3.5) i Aptana Studio 2.0.5 Stable - wersja 3 ciągle była (i jest) w fazie beta i nie współpracowała z Eclipse Helios (3.6). Dało się zainstalować Studio 2.0.5 na Heliosie, ale był to wielki błąd z mojej strony - nie mogłem uruchomić Menadżera Rozszerzeń właśnie przez brak wsparcia dla nowego wydania Eclipse.

Samego procesu instalacji pluginu nie będę tu przedstawiał, gdyż jest bardzo prosty. Zwrócę tylko uwagę na instalację pluginu jQuery w Aptanie. Po zainstalowaniu dodatku i ponownym uruchomieniu całego środowiska naszym oczom powinna się ukazać strona startowa My Studio:


Wybieramy Plugins -> AJAX i z długiej listy możliwych bibliotek wybieramy jQuery Support (wciskamy Get it):


Z listy, która się pojawi wybieramy obie wersje biblioteki jQuery: 1.3.2 oraz 1.4.2:


Dalej instalacja przebiega standardowo. Dzięki tandemowi Aptana Studio + jQuery Support możemy w pełni cieszyć się z wsparcia dla jQuery (jak i czystego JavaScript'u) w Eclipse :)


Na sam koniec chciałbym podzielić się dwoma wskazówkami do używania pluginu do jQuery - Autocomplete:

1) Bezpieczniejsze wyświetlanie podpowiedzi - ponieważ Autocomplete w żadnej mierze nie zabezpiecza wyświetlanych podpowiedzi, musimy to zrobić za niego. W tym celu jako drugi argument metody autocomplete musimy przekazać taką strukturę:

$("#autocompleteDOMObject").autocomplete(data, {
formatItem: function(row, i, max) {
return "" + new String(row[0]).replace(/&/g, '&').replace(//g, '>') + "";
},
formatMatch: function(row, i, max) {
return row[0];
}
}
Funkcja formatItem odpowiada za wyświetlanie kolejnych podpowiedzi, dlatego musimy zastąpić znaki '<', '>' oraz '&' odpowiednimi kodami, aby były one wyświetlane zamiast interpretowane. Metoda formatMatch musi natomiast zwracać kolejne pozycje bez zamiany znaków, gdyż po tych znakach (które wprowadził użytkownik) każemy pluginowi wyszukiwać.

2) Wyszukiwanie nie tylko od początku zdania - jeśli chcemy, aby plugin wyszukiwał także dopasowania słów, które nie są pierwszymi słowami w danym zdaniu/łańcuchu, musimy jako drugi argument autocomplete podać:

$("#autocompleteDOMObject").autocomplete(data, {
matchContains: "word",
autoFill: false
}
oraz wyedytować plik zawierający skrypt autocomplete:


function matchSubset(s, sub) {
if (!options.matchCase)
s = s.toLowerCase();
var i = s.indexOf(sub);
if (options.matchContains == "word"){
i = s.toLowerCase().search("\\b[^0-9a-zA-Z]" + sub.toLowerCase());
}
if (i == -1)
return false;

return i == 0 || options.matchContains;
};
Parametr matchContains z wartością "word" mówi pluginowi, że ma wyszukiwać także słów wewnątrz łańcucha znaków. To, co zrobiliśmy w pliku ze skryptem pluginu to zamieniliśmy wyrażenie regularne na takie, które zapewnia nas, że brane będą pod uwagę jedynie "słowa", które nie zaczynają się żadnym znakiem specjalnym.

Na dzisiaj to tyle. Drugi post może nie jest tak bogaty jak poprzedni, ale mam nadzieję, że znajdzie się ktoś, komu zawarte tutaj informacje się przydadzą :)

Pozdrawiam i do następnego razu!

Przemyślenia praktykanta #3

Witam!

Moje praktyki trwają już ponad miesiąc (pozostały jeszcze dwa) i był to wspaniały okres, który oprócz ogromnej porcji wiedzy, doświadczenia i przyjemnej pracy dostarczył mi wiele powodów do zatrzymania się i porządnego zastanowienia (o czym można już było przeczytać już tutaj i tutaj). Sądzę, że jest to najlepszy moment na podzielenie się kolejną porcją przemyśleń. A więc do dzieła :)

10) Nie bójmy się porażek - stare przysłowie mówi: "Kto nie gra, ten nie wygra" i uważam, że idealnie pasuje ono do okresu praktykowania. Jeżeli nie będziemy próbowali sparaliżowani perspektywą porażki lub (co jest niedorzecznością w trakcie praktyk, ale i później także w dużym stopniu) ośmieszenia się przed resztą zespołu to nigdy nie dowiemy się, czy nasz pomysł jest dobry, czy zły, nie będziemy wiedzieli wiedzieli w przyszłości, czy tego typu rozwiązań powinno się unikać, jakie niosą za sobą konsekwencje etc. Nie wierzmy na słowo, sprawdzajmy swoje pomysły, bawmy się przy metodzie prób i błędów.

11) Nie bójmy się zmian - po jakichś 3 tygodniach pracy nad projektem, który przydzielono mi na samym początku praktyk odbyłem bardzo długą rozmowę z opiekunem praktyk, każdy z nas podzielił się z drugim wrażeniami odnośnie wykonywanego projektu, jego szans, moich dotychczasowych umiejętności, priorytetów firmy i wielu, wielu innych spraw. Jaki był skutek tej rozmowy? Postanowiliśmy zarzucić obecnie wykonywany projekt i przejść w trochę inny rodzaj, w dodatku już w trakcie tworzenia przez pewną grupę. Z początku było mi ciężko dopisywać ostatnie linijki kodu do starego projektu (ustaliliśmy, że nie zostawiamy nieskończonych task'ów i że przejdę dopiero po wykonaniu wszystkich zadań jakie mi opiekun wcześniej wyznaczył), ale potem doszło do mnie, że ta zmiana może okazać się dużą szansą - i tak faktycznie było! Mam okazję na co dzień współpracować z grupą (małą, ale dzięki temu nie czuję się przytłoczony) doświadczonych developerów i podpatrywać ich w akcji :)

12) Nie jesteśmy robotami - Tamtego dnia, gdy postanowiliśmy ze Sławkiem, że kończymy pracę nad jednym projektem, a zaczynami nad drugim, nasza rozmowa była najdłuższą czynnością jaką wykonałem, ale okazała się najbogatsza w wiedzę, możliwość spojrzenia na projekt okiem kogoś, kto nim zarządza. Do czego zmierzam? Do tego, że nikt nie oczekuje, iż będziemy siedzieli przed komputerem pełne 8 godzin od 9 do 17, nie wytykając nosa poza box poza krótką przerwą na drugie śniadanie. Czasem krótki czas spędzony daleko od biurka może przynieść więcej korzyści, niż kilka godzin siedzenia na tyłku męcząc się z jakimś zagadnieniem. Dla mnie takim miejscem odsapnięcia jest kuchnia (z uwagi na ekspres do kawy ;) ) i muszę przyznać, że rozmowy tam (a także ich brak, gdy nikogo w kuchni nie ma) potrafiły przybliżyć mnie do rozwiązania problemu bardziej niż siedzenie z tym problem tête à tête przez pół dnia.

13) You Ain't Gonna Need It - czyli w skrócie YAGNI, jest zasadą mówiącą, że powinniśmy dodawać do projektu nową funkcjonalność dopiero w momencie, gdy ta funkcjonalność jest niezbędna. Dzięki temu unikamy nadmiernego rozrostu projektu i koncentrujemy się (a co za tym idzie lepiej wykonujemy) na tym, co najważniejsze. Osobiście miałem ten problem przy swoim pierwszym samodzielnym projekcie na praktykach - zacząłem dodawać nowe funkcjonalności nie pokrywając dostatecznie testami już stworzonych i po niedługim czasie mój system był dziurawy jak ser szwajcarski, duży, ale z małą ilością prawdziwej funkcjonalności. Na całe szczęście mam opiekuna, który w każdej chwili jest gotów ściągnąć mnie na ziemię i wskazać najodpowiedniejszy kierunek działań :) Jest to bardzo dobre, póki jeszcze sami nie jesteśmy w stanie dostrzegać i wykonywać najistotniejszych zadań w pierwszej kolejności. Wydaje się, że stoi to w sprzeczności z podchodzeniem do pracy z postawą eksperymentatora i metodą prób i błędów? Nie będę sam wynajdywał koła i powołam się na artykuł kogoś, kto umie to wytłumaczyć znacznie lepiej ode mnie - mówię tu o artykule "Bo w życiu trzeba... być Agile:)" Sławomira Sobótki.

14) Nie taka dokumentacja zła jak ją malują - w obecnych czasach podobno zaledwie kilka firm na świecie przyznaje się do tego, że nie jest "zwinna", raptem jedna indyjska firma oficjalnie ogłosiła, że nie jest firmą pracującą w oparciu o zwinne metodyki. A z czym ludziom kojarzy się zwinna firma? Z brakiem dokumentacji, z końcem biurokracji itp. Ale czy naprawdę dokumentacja jest takim złem? Kiedy w zeszłym tygodniu zmieniłem projekt, za zadanie miałem (i nadal mam) uzupełnienie i aktualizacja dokumentacji tegoż projektu. Z początku bardzo mi się to nie spodobało, ale po kilku godzinach badania projektu zdałem sobie sprawę, że jest to idealna okazja na dogłębne poznanie obszaru, nad którym mam pracować. Daje mi to też możliwość zadawać trudne pytania autorom konkretnych fragmentów kodu, jeżeli jakieś zachowanie jest niejasne lub zwyczajnie nie działa tak jak do tej pory było to opisane. Po dwóch dniach spędzonych nad dokumentacją dostałem do wykonania proste zadanie poprawy drobnego kawałka kodu i dzięki zdobytej wiedzy rozwiązanie problemu zajęło (dosłownie!) 5 minut wraz z przetestowaniem.

Na razie to wszystko. Pozdrawiam i do następnego razu! :)

wtorek, 20 lipca 2010

Duża porcja filmików

Witam!

Ostatnio zastanawiałem się czemu Miško Hevery nie publikuje nic na swoim blogu, gdy w tym momencie pojawiła się wiadomość w czytniku RSS o jego nowej publikacji. Miško jest bardzo utalentowanym, chętnym do dzieleniem się swoją wiedzą i rozmowy programistą, który od jakiegoś czasu dosyć często pojawia się w cyklu Google Tech Talks. Nie inaczej było tym razem - Miško Hevery wygłosił prezentację na temat "How JavaScript works", która jak dla mnie jest rewelacyjna, gdyż dopiero teraz zaczynam zabawę z JavaScript. Nie jest to prezentacja, która ma za zadanie nauczyć nas pisać skrypty JS, ale wytłumaczyć czemu pewne rzeczy się dzieją i co może być często problemem wynikającym z nierozumienia samej zasady działania języka. Film trwa godzinę, ale naprawdę dobrze się go ogląda - gorąco polecam:



Dodatkowo rozmawiałem ostatnio z Leszkiem Gruchałą, organizatorem konferencji java4people w Szczecinie na temat filmików z ostatniej edycji. Konferencję tą darze szczególnym sentymentem, gdyż była to moja pierwsza konferencja dla developerów w życiu, a wrażenia i wiedza z niej wyniesiona do tej pory procentują :) Okazało się, że są one dostępne na łamach portalu Parleys.com (należy przejść do działu Spaces -> Only JUGs -> Szczecin JUG). Oto kilka najciekawszych moim zdaniem:

"Comet & Beyeux" autorstwa Waldemara Kota:




"Zwinne i lekkie aplikacje webowe z Grails" Jacka Laskowskiego (jeszcze bez swojego śrebrnego MacBook'a ;)):





"System kontroli wersji GIT" Andrzeja Śliwy



To na dziś tyle. Czas iść spać, żeby jutro wypoczętym przyjść na praktyki i zgłębiać się w temat RESTful Services :) Do następnego razu!

sobota, 17 lipca 2010

Przemyślenia praktykanta #2

Witam!

Od mojego ostatniego postu minęło raptem cztery dni, ale nawet w tak krótkim czasie pojawiło się kilka przemyśleń, olśnień, a także postanowień. To jest dla mnie kwintesencja praktyk - zmuszają nie tylko do działania (w moim przypadku kodowania), ale w większym stopniu do myślenia, stawiania czoła problemom i otwieraniu się na nowe (choć z pewną dozą zdrowej podejrzliwości).

7) Nie zabieraj pracy do domu! - przez pierwsze dni była to moja zmora. Siedziałem w firmie po 9 godzin, a po przyjściu do domu zamiast się zrelaksować, siadałem nad problemem by do późnych godzin tak naprawdę niewiele posunąć się do przodu. Dlaczego tak było? Ponieważ nie miałem w koło siebie grupy fachowców w każdej chwili gotowej mi pomóc, ponieważ nie zapewniłem sobie należytego relaksu. Po kilku dniach i lekturze Rework (znów ten Rework :)) uświadomiłem sobie, że jeżeli wszystkie zmartwienia i problemy związane z praktykami będę zostawiał w firmie, po pracy będę w stanie naładować swoje akumulatorki, aby następnego dnia stawić czoła wyzwaniu/przeciwności z pełnią sił i determinacji. Robiąc inaczej tylko podcinamy sobie skrzydła i w naprawdę krótkim czasie skazujemy siebie samych na wypalenie, po którym z odpowiedniego "chce" zrobi się śmiercionośne "muszę". Od kiedy wprowadziłem do życia tę zasadę osiągam więcej i szybciej, a najlepsze jest to, że robię to z przyjemnością!

8) Nawet najmniejszy unit test może rozjaśnić Twój dzień - dwa dni straciłem nad pewnym zagadnieniem numerycznym. Męczyłem się z doborem odpowiedniej biblioteki, potem z jej integracją, by na końcu zawsze okazywało się, że nie spełnia ona naszych wymagań. Zamiast iść do przodu, stałem w miejscu i przestawało mi się chcieć. Trzeciego dnia zmagań poszedłem do Sławka i namówił mnie do napisania swojego rozwiązania, ale z możliwie najmniejszą funkcjonalnością. Po jakiejś pół godzinie, gdy uruchomiłem pierwszy test i zobaczyłem wiadomość "Failure: 0" od razu się uśmiechnąłem i nabrałem chęci do pracy. Tak napędzony przez kolejne kilka godzin pracowałem dodając nowe testy i przez większość czasu uśmiechając się do siebie samego, nawet wtedy gdy nie wiedziałem jak mam to, czy tamto poprawić. Starałem się nie wprowadzać zbyt wielu modyfikacji naraz, aby móc dobrze przetestować całość. Efekt? Pod koniec dnia przyszedłem do Sławka z gotowym rozwiązaniem, pokrytym testami i spełniającym wszystkie nasze wymagania. Od tej pory staram się wyszukiwać nawet najmniejsze rzeczy, które wiem, że uda mi się zrobić szybko i poprawnie, co doda mi sił i motywacji do pracy - to naprawdę działa :)

9) Utrzymuj rzeczy możliwie najprostszymi - jednym z problemów, który miałem przy zagadnieniu, o którym pisałem wcześniej było to, że zbytnio chciałem je rozbudowywać i to od samego początku. Brało się to z nauki, którą wpaja się na uczelniach wyższych (a przynajmniej na obu kierunkach, na których byłem - mam nadzieję, że gdzieś jest inaczej) - od samego początku myśl i projektuj i koduj z myślą o pełnej funkcjonalności systemu. Ten prosty problem pokazał mi, że oczywiście należy przewidywać możliwą rozbudowę systemu, ale nie należy jej wprowadzać od pierwszych chwil jego życia. Kiedy mój opiekun wskazał mi kluczowe zagadnienia, którymi musi zając się moja biblioteka sprawa nagle stała się kilkakrotnie prostsza i możliwa do zaimplementowania w ciągu jednego dnia. Dzięki temu mam gotowy szkielet, który w niedługiej przyszłości mam zamiar rozwijać, ale na dzień dzisiejszy jest już działający i jest wykorzystywany. Gdybym zabrał się za pełną (lub choćby połowiczną) potencjalną funkcjonalność od pierwszych chwil nie miałbym tego gotowego przed końcem roku, a co dopiero końcem praktyk.

Na dzisiaj to tyle. Czas się wyspać, jutro też jest dzień (może na napisanie kolejnego postu? :)).
Pozdrawiam i do następnego razu!

wtorek, 13 lipca 2010

Przemyślenia praktykanta #1

Witam!

Ostatni okres nie był dla mnie łatwy. Zacząłem praktyki i tak jak na samym początku sądziłem, że będzie super produktywnie, pracowicie i entuzjastycznie, tak po niecałych dwóch tygodniach jedyne co bym z tego zdania pozostawił to pracowicie. A co z resztą? To trudne pytanie, na które cały czas nie znalazłem (i pewnie długo jeszcze nie znajdę) pełnej odpowiedzi. Do przemyśleń skłoniła mnie książka, którą właśnie czytam - Rework - Jasona Fried'a oraz Davida Heinemeier Hansson'a (z firmy 37signals - twórców m.in. Ruby on Rails), o której niedługo trochę szerzej napiszę na blogu. Ale do rzeczy:

1) Są wakacje! - nim jeszcze zacząłem praktyki miałem wielkie plany na wakacje: bieganie z samego rana, praktyki od 8 do 16, potem coś zjeść, praca inżynierska oraz jeden z 2 projektów, w których mam brać udział i spać - idiotyzm. Czas wakacji to przede wszystkim czas odpoczynku, relaksu, nabrania sił na boje kolejnego roku akademickiego. Bardzo dobrze podchodzą do tego panowie od marketingu w wydawnictwie ISA - w swoim newsletterze piszą:
Wakacje, to czas wytchnienia od nauki i pracy. Wolny czas można zagospodarować na 1001 sposobów. Proponujemy, aby część tego czasu spędzić z ciekawą lekturą.
To nie musi być książka, równie dobrze można iść na plażę, do lasu, na rower i etc. etc. Sens jest w tym, by znaleźć coś, co nas relaksuje i pomaga się odprężyć.

2) Jesteś na praktykach, nie w pracy - Mateusz bez przerwy mi to powtarza. Praktyki to czas nauki, nikt nie oczekuje, że w ciągu miesiąca (czy jak w moim przypadku trzech) praktykant zbuduje "nowe, lepsze Google". Oczywiście większość praktykantów, którzy zaczynają w dobrej firmie, chciałaby po skończeniu praktyk dalej współpracować z firmą - ja sam tak miałem/mam. Ale bardzo szybko okazuje się to bardzo zgubne. Przy każdej rzeczy, jaką się wykonuje myślenie zamiast kierować się ku rozwiązaniu idzie w kierunku zadowolenia szefa, czy się przypadkiem nie ośmieszymy etc. Tak jest często, jeśli nie jesteśmy pewni swojej wartości na rynku, a bardzo byśmy chcieli być widziani jak najlepiej. Takimi sprawami powinniśmy się martwić dopiero pod koniec lub na sam koniec praktyk, a do tej pory starać się robić zwyczajnie swoje i uczyć się przy tym jak najwięcej. Czy będziemy dalej pracować w tej firmie, czy nie - doświadczenie i tak wyniesiemy, a przecież po to idziemy na praktyki, prawda? :)

3) Refaktoryzacja - oto klucz do łatwiejszej nauki. Bardzo często łapie się na tym, że chce wykonać dane zadanie tak dobrze, że już nie wiem jak do tego podejść. Liznąłem temat TDD - no to piszemy testy, poznałem metodę DRY/KISS/itp. - od samego początku piszę kod zgodny z nimi wszystkimi etc. Przykładów można wymieniać mnóstwo i oczywiście przesadzam, ale mam nadzieję, że idea jest jasna. Dopiero dzisiaj uświadomiłem sobie, że moje podejście jest błędne. Brak mi doświadczenia, żeby pisać ładny, dobry produkcyjny kod. Dlatego zacząłem robić coś innego, za namową bardziej doświadczonych ode mnie - tworzę jakieś rozwiązanie, najłatwiej jak się da. Potem gdy już osiągnę cel zastanawiam się (jeśli jest na to czas oczywiście), czy da się to zrobić lepiej i jeśli tak, próbuje tak zrobić, ale nie wkładając w to za dużo czasu/wysiłku, tak by znajdywanie tego rozwiązania nie było męką, tylko przyjemnością. Jeśli jestem zadowolony z rozwiązania (a u mnie to oznacza możliwość "łatwej" integracji z całością, którą tworzę) zostawiam temat i przechodzę do następnego zagadnienia. Na artyzm przyjdzie jeszcze czas, a jest tyle do nauczenia się :) Bardzo często w nauce danego tematu nie chodzi o poznanie konkretnej technologii, ale bardziej o ideę, którą ona realizuje - wtedy nie ma sensu zbytnio się przejmować pięknem rozwiązania. Dużo czasu przez to straciłem, ale mam nadzieję, że wreszcie przejrzę na oczy :)

4) Nie wszystko naraz! - kiedy idzie się na praktyki bardzo często ma się wrażenie, że od samego początku będzie się uczyło nie wiadomo ilu i jak wysublimowanych technik/narzędzi/ideologii/metodyk. Przez takie podejście bardzo łatwo utknąć w martwym punkcie, gdzie nie wiadomo czego się chwycić. Ja sam tak często miałem przed praktykami, ale na szczęście mój opiekun w Spartezie (Sławek) bardzo szybko sprowadza mnie na ziemię. Najczęściej idziemy sobie zrobić kawkę i dyskutujemy o tym co można by było zrobić dalej, wybierając jedną ze ścieżek. Nie ma tak, żeby łapać się kilku rzeczy naraz - w ten sposób w jednostce czasu nie zrobisz tak naprawdę nic, a jeśli będziesz robić po kolei, każdej z tych rzeczy nauczysz się lepiej i dokładniej.

5) Jeśli naprawdę nie masz co robić, idź do domu - często znajomi opowiadają mi jak to na praktykach siedzieli 8h bezczynnie, tępo oglądając filmiki na YouTube lub grając w gierki na Facebook'u - to totalnie bez sensu. Jeśli w danym dniu zrobiło się już wszystko, co zostało zaplanowane, a następny krok jest na tyle obszerny i trudny (nieprzyjemny?!), a czasu stosunkowo za mało, tak że musielibyśmy jutro zaczynać i tak od nowa - poprośmy szefa o możliwość pójścia do domu. Lepiej wypocząć w domu, nabrać sił na kolejny dzień, niż męczyć się ciągnąć do tych 8 godzin dla samej zasady i skazując się na zmęczenie czy też brak pozytywnego podejścia następnego dnia. Na moich praktykach nie mam rygoru przychodzenia na konkretną godzinę. Mamy ustalony plan działań i w pewnym przedziale trzeba to zrobić. Dzięki luźniejszemu podejściu w momencie gdy czułem się gorzej mogłem spokojnie poleżeć w łóżku, by przyjechać do firmy wypoczęty. Nie miałem stresu, więc i robota szła lepiej. Dla samokontroli zapisuje sobie godziny przyjścia i wyjścia (oczywiście mniej więcej) i ku mojemu zdziwieniu przesiedziałem od początku praktyk więcej godzin, niż wynosi pracownicze minimum, a zrobiłem to z chęcią i nawet tego nie poczułem.

6) Kiedy masz problem - nie bój się zapytać innych - nic nie jest lepszym źródłem wiedzy niż doświadczenie starszych stażem! Już na samym początku praktyk dowiedziałem się, że będę musiał nauczyć się zagadnień z wielu dziedzin. Wiadomo, że nie każdy zna się na wszystkim, tak więc trzeba próbować aż do skutku. Nie mówię, że należy z najmniejszą rzeczą biegać po całym biurze siejąc popłoch. Mam to szczęście, że choć w firmie, w której robię praktyki każdy ma bardzo solidne podstawy z wiedzy ogólnej, już po chwili udało mi się rozpoznać kogo mogę o co pytać. Jedni podpowiedzą jak czegoś wyszukać, inni usiądą i zrobią z Tobą krótkie Code Review, jeszcze inni naprowadzą na rozwiązanie samymi pytaniami na temat problemu, ale wszyscy wyznają jedną zasadę - jeśli ktoś poprosi o pomoc - nie odmówią. Co jeszcze lepsze - kiedy już pomogą Ci znaleźć rozwiązanie będą ciekawi jak Ci poszło. Ostatnio w ten sposób bardzo miło zaskoczył mnie jeden z członków zespołu - dopytywałem się go o RESTful Services budowane w oparciu o framework Jersey i tego samego dnia, a także następnego przez pytania o to, czy udało mi się rozwiązać problem dowiedziałem się masy nowych rzeczy (nie dziwota, bo temat dla mnie całkowicie nowy) i to w jednym z najprzyjemniejszych sposobów - przez rozmowę. Tak więc nie należy bać się zadawać pytań, bo w ten sposób może umknąć nam wiele niuansów, których próżno szukać w (nie)oficjalnych dokumentacjach.

Trochę przydługi wpis mi wyszedł, ale przynajmniej znalazłem formę na wyrażenie swoich myśli :) Pozdrawiam i do następnego razu!

wtorek, 6 lipca 2010

Problem z m2eclipse

Witam!

Jaki Eclipse jest - każdy widzi i większość wie. W trakcie niedawno rozpoczętych praktyk często spotykam się z opinią, że Eclipsem nie warto sobie w ogóle głowy zawracać, że jest kompletnie bezużyteczny etc. etc. Osobiście twierdzę, że mając na głowie mnóstwo rzeczy, których muszę się nauczyć "na wczoraj" (lista postanowień noworocznych to przy tym pikuś ;)), zawracanie sobie głowy nauką i przyzwyczajaniem się do nowego IDE było by mało efektywne. Dlatego uparcie trzymam się Eclipsa i prę dalej. Miało być o problemie z integracją Eclipse Galileo z Mavenem, ale najpierw jeszcze sam nawrzucam na moje ukochane IDE. bo co za dużo, to niezdrowo:
  • Eclipse Helios po wielu próbach i ogromnej ilości dobrych chęci okazał się totalnie bezużyteczny do pracy z Google App Engine, AJAX'em, jQuery etc. Pluginy odpowiedzialne za wsparcie dla tych technologii/narzędzi zwyczajnie nie są kompatybilne z najnowszą wersją Eclipsa...
  • Na potrzeby napisania tego postu wróciłem dzisiaj na chwilę do Eclipse Galileo na Windows 7 i oto jaki komunikat otrzymałem przy starcie aplikacji (nie wymaga chyba komentarza):
A teraz wracając do integracji Mavena z Eclipse Galileo (na Heliosie nawet nie pomyślałem, żeby to sprawdzić) - prostym rozwiązaniem wydawać by się mógłby się wydać wybór wtyczki m2eclipse. I tak jest, ale osobiście srodze się zawiodłem już na samym początku. Pierwszy problem to fakt, że Eclipse z natury uruchamia aplikacje za pomocą JRE, a nie JDK. Aby to zmienić musimy w Window -> Preferences -> Java -> Installed JRE's ustawić jako domyślne JRE z JDK. Klikamy Add ...

... wybieramy Standard VM ...

... i w Directory wpisujemy adres zainstalowanego w systemie JDK

Potem wybieramy go jako domyślny na liście JRE i klikamy OK:

Wyłączamy Eclipse i otwieramy plik konfiguracyjny eclipse.ini (w głównym katalogu Eclipse). PRZED parametrem -vmargs dodajemy parametr -vm, a linijkę niżej podajemy ścieżkę do JRE. U mnie wygląda to następująco:

Pamiętajmy, by nie podawać ścieżek ze spacjami oraz używać '\\' lub '/' zamiast standardowego '\' Windowsa! Uruchamiamy Eclipse i cieszymy się wtyczką m2eclipse :)

Jeśli zaimportujemy projekt stworzony już wcześniej (File -> Import -> Existing Maven Projects) i spróbujemy wykonać Maven install z menu rozwijanego Run as możemy otrzymać taki oto komunikat:


Could not calculate build plan: Missing:
----------
1) org.apache.maven.plugins:maven-resources-plugin:maven-plugin:2.4.1
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.apache.maven.plugins -DartifactId=maven-resources-plugin -Dversion=2.4.1 -Dpackaging=maven-plugin -Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file there:
mvn deploy:deploy-file -DgroupId=org.apache.maven.plugins -DartifactId=maven-resources-plugin -Dversion=2.4.1 -Dpackaging=maven-plugin -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
----------
1 required artifact is missing.
for artifact:
org.apache.maven.plugins:maven-resources-plugin:maven-plugin:2.4.1
from the specified remote repositories:
central (http://repo1.maven.org/maven2, releases=true, snapshots=false)





Aby temu zaradzić musimy do POM'a dodać w sekcji build taki oto wpis o używaniu resource-plugin w nowszej wersji (np. 2.4.2). Całość wygląda następująco:

Teraz po wykonaniu komendy install w katalogu target znajdziemy nasz "wymarzony" plik JAR. Trochę (za)dużo zachodu, prawda? Niestety, takie właśnie są uroki używania Eclipse...

Mam nadzieję, że komuś przyda się ta informacja. Ja walczyłem ponad godzinę z Eclipse nim Maven zaczął mi w nim "działać". Bardzo pomocne okazały się wpis na Victoria's blog, Stackoverflow oraz komentarz Nikola na blogu Bright Side.

Pozdrawiam i do następnego razu!

piątek, 2 lipca 2010

Cytaty #4

Witam!

Trafiłem dzisiaj na bardzo ciekawy i bardzo trafny artykuł Sławka Sobótki na temat podejścia Agile, w którym to napisał:
Gdy jednak przyjrzeć się bliżej, to z tym Agile jest jak z seksem u nastolatków - każdy o tym mówi ale niewielu tak na prawdę to robi (a przynajmniej tak było kilkanaście lat temu w klasach mat-inf;).
Jeśli sam autor nie zachęcił Was do przeczytania tego niedługiego (wyjątkowo :P) wpisu, to może ten cytat to zrobi :)

Pozdrawiam i do następnego razu!

czwartek, 1 lipca 2010

Pierwszy dzień praktyk

Witam!

Właśnie wróciłem z pierwszego dnia praktyk wakacyjnych w firmie Spartez.com :) Wrażeń było co niemiara, ale od początku :)

Przyjechałem do firmy punktualnie o 8 (sam jestem zdziwiony, że udało mi się wstać :D) i narobiłem tym trochę zamieszania, bo nie było nikogo, kto by wiedział co mam robić albo gdzie siedzieć. Ale szybko udało się temu zaradzić i przyszedł czas na pierwsze zadanie - przygotowanie miejsca pracy. Byłem tak zestresowany pierwszym dniem, że do złożenia biurka podchodziłem 3 razy - ponoć do trzech razy sztuka... Gdy biurko w końcu stało trzeba było złożyć fotel (który nawiasem mówiąc spowodował wiele wiązanek, gdyż jest skórzany i wygląda jak fotel jakiegoś prezesa w banku :)) i tu znów pojawiły się problemy, ale metodą "małych kroczków i dużego młotka" udało się i z tym poradzić (choć ręce nadal mi dygotały). W czasie składania przyszła kolejna nowa osoba w zespole - student ETI imieniem Krzysiek.

Około godziny 10 przyszedł czas na Standup Meeting - mój pierwszy meeting scrumowy :) Wrażenia bardzo pozytywne i nie mogę się doczekać kolejnego :D Spotkanie było wyjątkowe, bo cała firma się zebrała, a to dlatego, żeby łatwiej nas (nowych) poznać z resztą zespołu.

Po standup'ie dowiedziałem się nad czym będę pracować przez najbliższe 3 miesiące i muszę powiedzieć, że projekt nie dość, że jest ciekawy technologicznie to w dodatku mi się spodobał i od samego początku przyjemnie mi się nad nim pracowało :) Reszta dnia upłynęła na robieniu ogromnego sajgonu na wirtualnej maszynie (Ubuntu + Eclipse x4 + Google App Engine Plugin to jakby samemu prosić się o kłopoty :D) i poznawaniu podstaw pracy z Google App Engine. W jednym z moich poprzednich wpisów pisałem o Eclipse Helios. Przygotowałem sobie specjalnie na dzisiaj czystą wersję, aby móc na nim pracować, ale spotkało mnie ogromne rozczarowanie - Google App Engine Plugin nie współpracuje z wersją Eclipse wyższą niż 3.5.x i trzeba było wrócić szybko do Galileo, a szkoda. Ale nawet to nie ostudziło mojego zapału do pracy :) Niestety o godzinie 15:30 padł prąd w całym budynku (awaria w Enerdze jak się później dowiedzieliśmy), która trwała prawie godzinę, tak więc po pewnym czasie zwinąłem się już do domu, bo nawet sieci nie było (a bez niej i tutoriali).

Podsumowując: tak jak byłem przerażony wizją praktyk wakacyjnych, tak teraz nie mogę się doczekać kiedy znów usiądę znów przy swoim biurku i będę mógł dalej pracować nad projektem! Ciekawe tylko jak długo takie nastawienie mi się utrzyma ;)

Pozdrawiam i do następnego razu!