Go to Top

Z życia praktykanta Kroll Ontrack. Część 1

praktyki w Kroll Ontrack

Przedstawiam Wam dziennik, który napisałem w trakcie odbywania miesięcznych praktyk w Kroll Ontrack. Zapraszam do czytania! 

Dzień pierwszy

Spodziewałem się, że będzie gorzej. Bałem się, że już na wstępie będę musiał zmierzyć się z masą zadań, których, kolokwialnie mówiąc, nie będę w stanie ogarnąć. Jednak zamiast tego okazało się, że… mój komputer nie działa. Miałem zatem czas, by zwiedzić firmę – pierwszy raz zobaczyłem prawdziwy Daily Scrum oraz Retrospektywę. Po wszystkim firmowy obiad… Gdy wróciliśmy, mój komputer został podmieniony, więc w końcu mogłem zacząć czytać kod. Poza tym tego dnia niesamowicie się uśmiałem 🙂

Dzień drugi

Prawdę mówiąc, niewiele dowiedziałem się z samego czytania kodu. Dopiero dzisiaj Witek opowiedział mi, co tak naprawdę robimy. Potem wraz z Łukaszem (właściwie to sam Łukasz) zaczęliśmy poprawiać metodę, o której rozmawialiśmy dzień wcześniej na spotkaniu. Nie chciałem spowalniać pracy ciągle o coś pytając, ale Łukasz wykazał się ogromną cierpliwością i wytłumaczył mi wszystko po kolei tak, że zrozumiałem, co się tam tak właściwie dzieje. Pod koniec dniówki dostałem zarys własnego zadania na następny dzień.

Dzień trzeci

Zacząłem robić swoje zadanie, ale początkowo nie szło mi najlepiej. Ciągle dopytywałem o kolejne rzeczy, aż w końcu udało mi się napisać test. Jako że metoda, którą testowałem, nie była jeszcze gotowa, test miał nie przechodzić. Zamiast tego, w ogóle nie zadziałał i resztę dnia spędziłem na szukaniu błędu. W międzyczasie w firmie nagrywano film o poszczególnych zespołach, a na koniec dnia „zabrakło” prądu, przez co nadal nie znalazłem rozwiązania problemu. Tego dnia dowiedziałem się też, że trzeba blokować komputer, gdy odchodzi się od biurka, bo tapeta może się „sama” zmienić, lub jakieś maile mogą się „same” wysłać. Na szczęście do tej pory jakiś dobry duszek blokował mój komputer 🙂

Dzień czwarty

Razem z Tomkiem znaleźliśmy błąd, który okazał się naprawdę banalny. Chociaż z drugiej strony nie wiem, czy w pierwszej kolejności pomyślałbym, że to właśnie „to”. Z pomocą połowy teamu udało mi się skończyć pierwszego taska, a później z nieocenioną pomocą Kasi poprosiłem o przegląd kodu. Poza tym poznałem trochę lepiej codzienną pracę, np. jak wyglądają rozmowy z Product Ownerem i komunikacja z innymi zespołami zajmującymi się projektem. Po wszystkim zacząłem drugie zadanie i zauważyłem, że powoli zaczynam rozumieć, co się dzieje w kodzie i aplikacji.

Dzień piąty

Znowu przy pomocy połowy zespołu pisałem swoje zadanie. Po kilku wersjach tego samego schematu udało mi się znaleźć właściwe rozwiązanie. Samo napisanie kodu było proste, ponieważ nic nie trzeba było „mockować”. Pod koniec zmiany wrzuciłem moje zadanie na TFS. Łatwo poszło.

Dzień szósty

Zbliża się czas wypuszczenia części aplikacji, dlatego nie dziwię się, że dostałem zadanie niezwiązane z projektem, nad którym pracuje firma. Otóż zlecono mi rozwijanie aplikacji w WPF. Pierwszy raz (tak na 95%) wiedziałem, co się dzieje. W międzyczasie okazało się, że testy, które napisałem były złe, więc Tomek je zmodyfikował, a ja uruchamiałem aplikację w WPF. Poświęciłem na nią mnóstwo czasu, ponieważ nie używała paczek z Nugeta. Tuż przed wyjściem do domu udało mi się odpalić aplikację i sprawić, że zadziałała (względnie).

Przejdź do drugiej części.


Martin

, , , , ,

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *