Wieki mnie tu nie było, a całokształt pracy inżynierskiej ewoluował jak Charmander, zwany przez Agę pieszczotliwie Czarusiem, w Charizarda (zwanego oczywiście wciąż Czarusiem). Było trochę niedospanych nocy, czytania Wiedźmina w oczekiwaniu, aż okno konsoli będzie miało zamierzony kolor, było sporo nerwów, kilka "przeoczonych" terminów, po których zawsze opadał "szał bitewny", z którym jeszcze tuż przed deadlinem kodziłem i pisałem co trzeba. Ale w końcu się udało i, choć z półroczną obsuwą, 21 czerwca obroniłem się, o czym wspomniałem już na drugim blogu. Tutaj jednak, poza podaniem linka do pracy i prezentacji z obrony, będzie inaczej - o historii samej pracy i różnych napotkanych komplikacjach.
Pomijając już pierwotną wizję mojej pracy inżynierskiej, o której pisałem wcześniej, a którą porzuciłem już długo przed terminem składania prac, mój nowy temat ewoluował, gdy tak się do niego zabierałem mniejszymi, bądź większymi kroczkami i gdy sobie tak po prostu o nim myślałem. Plan, opisany w podlinkowanym wyżej poście, zakładał wprowadzenie w życie portalu internetowego zbierającego poradniki. Przez przeglądanie w tym czasie różnych ofert pracy poznałem w tym czasie pojęcie Behavior-Driven Development - pochodną TDD, której znajomości w niektórych ofertach oczekiwano, co zaowocowało myślą "A może nauczę się BDD tworząć Enklawę?". Byłoby to już upieczenie nawet trzech pieczeni na jednym ogniu, a nie dwóch - brzmiało smakowicie.
Tak więc zacząłem szukać co i jak w kwestii BDD w Rails, skoro już wybrałem ten framework do wykonania tego projektu. Znalazłem Cucumbera i zacząłem go ogarniać. Idea pisania scenariuszy mi się bardzo spodobała, więc jak tylko mogłem ściągnąłem odpowiednie gemy, co troszkę problemów z kompatybilnością mi przysporzyło przez wybranie Rails 2.3 do stworzenia Enklawy, gdy była już dostępna od dłuższej chwili wersja 3.0.1. Wynikało to z faktu, że znajdowane przeze mnie potencjalne hostingi wciąż właśnie trzymały się wersji 2.3, a pisanie aplikacji, którą sobie najwyżej na localhoscie mogę trzymać mnie nie cieszyło.
Pomęczyłem się troszkę, pokombinowałem i wydawało się, że będzie spoko. Jednak Cucumber miał problem z odpalaniem napisanych przeze mnie scenariuszy. Po chwili dotarło do mnie, że jest to wynikiem tego, że ścieżka do folderu z aplikacją zawierała polskie znaki - w końcu katalog nadrzędny projektu nazywał się "Enklawa twórcza". Po usunięciu drugiego słowa z jego nazwy zaczęło śmigać. Jednak ogólne podejście BDD zakładało wywalenie wszystkiego, co zacząłem robić wcześniej, w tym oczywiście rzeczy, które opisywałem tutaj. Niby prawie nic, ale też się troszkę bawiłem z tym generowaniem modeli na podstawie bazy i wcześniejszymi podejściami. No ale uznałem, że zdarza się szukać rozwiązań, które się i tak w efekcie nie przydadzą i że warto iść dalej już nową drogą. Scenariusze tworzyłem po angielsku zgodnie z podpatrzoną konwencją
ponownego wykorzystywania kroków, które były zdefiniowane w pliku features/step_definitions/webrat_steps.rb,
dodanym automatycznie przez Cucumbera. Wynikło to w sumie z tego, że
najpierw stworzyłem scenariusz zgodnie ze znajdowanymi przykładami, po
czym zdefiniowałem wszystkie występujące w nim kroki i po uruchomieniu
Cucumbera w konsoli dostałem info, że są już definicje takich kroków w
wyżej wspomnianym pliku, a moje w ogóle są jakieś do kitu.
Tak też złapałem już pewną konwencję i miałem zamiar się jej trzymać. W tzw. międzyczasie po rozmowie z Barnexem i Ktosem pewnego dnia, kiedy dowiedziałem się o Heroku, gdzie hosting aplikacji w Rails 3.0.1 jest darmowy do pewnego stopnia obciążenia serwera, co stało się idealną wizją na serwer tymczasowy, na czas publikowania wczesnych wersji Enklawy. Stworzyło to jednak pewien problem, który uwidocznił się po zainstalowaniu nowej wersji Rails i stworzenia szablonu aplikacji pod BDD - w najświeższej na ten czas wersji Cucumbera wycofano się z promowania używania kroków z pliku webrat_steps.rb. Nie ogarniałem trochę na początku co się stało z tym plikiem - w stworzonym projekcie go już nie było mimo, że katalogi samego Cucumbera były na swoim miejscu. Poszukałem trochę i dowiedziałem się o tym odejściu od tej konwencji. Miałem chwilę dylemat, czy trzymać się starego podejścia i skopiować sobie po prostu ten plik z miejsca, gdzie został na taką potrzebę "schowany", czy zacząć pisać od nowa. Po tej chwili w końcu postanowiłem iść zgodnie z myślą autorów i odpuścić sobie tamte definicje kroków.
Otworzyło to przede mną, jak się potem okazało, dodatkowe możliwości, które wydały mi się całkiem niezłe z perspektywy mojej pracy inżynierskiej. Uznałem, że skoro Cucumber umożliwia pisanie scenariuszy w wielu językach naturalnych, to czemu nie skorzystać z możliwości pisania ich po polsku? I to niestety spowodowało kolejne komplikacje i zabawę z nimi - na konsoli wyniki wyświetlały się z krzaczkami zamiast polskich znaków, czego nie dało się tak banalnie obejść, jak problemu z nazwą katalogu. Na szczęście po chwili szperania okazało się, że rozwiązanie zawiera się w trzech akcjach: zmienienie czcionki we właściwościach terminala z czcionki rastrowej na Lucida Console, uruchamianiu go z parametrem /U oraz wpisaniu zaraz po uruchomieniu polecenia chcp 65001. I wreszcie zaczęło śmigać i można było pisać.
Oczywiście nie był to koniec generalnych zmian związanych z moją pracą inżynierską. Kiedy zacząłem realizować koncepcję opisywaną do teraz zakładałem, że tworzę aplikację i przy okazji uczę się fajnej techniki, która do jej wytwarzania posłuży. Jednak, jak nam mówiono, ważnym elementem pracy jest bibliografia, więc musiałem sobie trochę książek do niej znaleźć, w tym "The Cucumber Book", "The RSpec Book", czy "Agile Web Development with Rails" - a gdy już je znalazłem, to wizja całości zaczęła mi się trochę zmieniać. Zacząłem większą wagę przywiązywać do tego, by przedstawić szerzej samą technikę BDD i coraz bardziej zaczynałem czuć, że robienie po prostu aplikacji w ramach pracy inżynierskiej to nie to, czego chcę. W ten oto sposób w trakcie pisania scenariuszy, definiowania do nich kroków i dopisywania odpowiedniego kodu do samej aplikacji przez doczytywanie ciągle czegoś w książkach postanowiłem zmodyfikować swoją koncepcję i omówić BDD na przykładzie wytwarzania Enklawy, a nie odwrotnie. I w takim duchu doprowadziłem całe przedsięwzięcie do końca, czyli do udanej obrony. Miałem przez chwilę zamiar korzystać nie tylko z Cucumbera, ale równiez z RSpec, ale pomyślałem o tym już po zrobieniu kawałka aplikacji i opisaniu tych etapów w pracy, więc odpuściłem sobie jednak.
Sama jednak praca nie wystarczy, żeby uzyskać tytuł - trzeba się jeszcze obronić, a do tego pasuje mieć prezentację. Po złożeniu wszystkich dokumentów, kiedy już tylko czekałem na dzień obrony zacząłem myśleć nad tym, jak podejść do tego tematu. I wymyśliłem - wpadłem na dość nietypową, przez co też trochę "niebezpieczną" koncepcję. Pomyślałem, że skoro moja praca była o tworzeniu wytwarzaniu oprogramowania sterowanym zachowaniem i scenariuszami je opisującymi, to również i prezentacja będzie przedstawiała ideę BDD. Kluczowym więc jej elementem był scenariusz pod tytułem "Obrona na 5.0", który służył również za agendę, w której celowo pominąłem krok związany z odpowiadaniem na pytania komisji, abym po zwróceniu przez kogoś uwagi na ten brak mógł powiedzieć o tym, że wykorzystanie BDD pozwala dość bezpiecznie dokonywać takich zmian przy ciągłym testowaniu poprawności tego, co już jest stworzone.
Zgodnie z moimi obawami był w komisji ktoś, komu moja koncepcja nie podeszła. Jeszcze zanim wszyscy przyszli i zacząłem prezentować, jak tylko podpiąłem się do rzutnika, jeden z członków komisji obecnych już na sali po zobaczeniu slajdu z opisem funkcjonalności "Obrona" kazał mi go natychmiast wyrzucić. Niby zakładałem, że moja wizja może się niekoniecznie spodobać, ale nie spodziewałem się czegoś takiego - przez to od razu skok ciśnienia i stres. Pytanie - usuwać, czy nie usuwać? Jak nie usunę, to mi się może oberwać od tego wykładowcy. Ale usuwanie było bez sensu, bo przecież zrobiłoby to tylko dziurę w całej koncepcji, której i tak, nawet jakbym chciał, nie zmieniłbym w te kilkadziesiąt sekund przed rozpoczęciem obrony. Postanowiłem więc zostawić i zobaczyć po prostu co z tego wszystkiego wyjdzie.
Oczywiście mówiło mi się ciężko przez ten stres, przez co też chyba dość sporo przekroczyłem przepisowe 10 minut prezentowania - tyle dobrze, że tylko ja się w ten dzień broniłem, a reszta osób z czerwca zdążyła dopiero na obronę tydzień później. Kiedy prezentowałem, to na twarzach komisji malowały się lekkie uśmiechy albo wyraz mówiąc "nie ogarniam" głównie. Po skończonej prezentacji przewodniczący komisji stwierdził z uśmiechem na twarzy, że to zbyt duży poziom abstrakcji dla niego był. Miał jakieś może trzy drobne uwagi, w tym oczekiwaną przeze mnie uwagę odnośnie braku odpowiadania na pytania w przedstawionym przeze mnie scenariuszu, ma co otwarcie odpowiedziałem, że miałem nadzieję, że takie stwierdzenie padnie i powiedziałem to, co sobie wymyśliłem mniej więcej jako odpowiedź na to, czym, wydaje mi się, zaplusowałem sobie troszkę. Żałowałem potem, że po slajdzie "Dziękuję za uwagę" nie miałem na tę okazję z dwóch dodatkowych, bo pokazałoby to, że faktycznie spodziewałem się tego i zaplanowałem to.
Potem przyszedł czas na pytania. Pierwsze zadał mój promotor, ale na na swoje nieszczęście zapytałem go czy mógłby doprecyzować - doprecyzował już ten wykładowca, który się doczepił mojej prezentacji na początku samym, więc poczułem, że zapowiada się grubo. Udzieliłem niepełnej odpowiedzi na to pierwsze pytanie, po czym dostałem od niego jeszcze co najmniej 4-5, choć w założeniu są 3 pytania generalnie na całą komisję w trakcie obrony. Na te pozostałe wszystkie udało mi się odpowiadać dobrze, choć czułem, że zadaje pytania tak, jakby chciał mnie zagiąć. Jak uznał już, że nie ma nic więcej do mnie, to reszta uznała, że już nie ma sensu zadawać więcej pytań, skoro już tyle poszło. Wyproszono mnie na kilka minut, żeby komisja mogła się naradzić. Pomyślałem przez chwilę, że skoro zadano mi więcej pytań, to uwzględnią w protokole te, na które mi się udało w pełni odpowiedzieć. Oczywiście po wezwaniu do sali okazało się, że uwzględniono to pierwsze pytanie, przy którym udzieliłem niepełnej odpowiedzi. Ostatecznie otrzymałem ocenę 4.5 - 5.0 miałem za samą pracę, 4.5 dostałem za prezentację, 4.0 za pierwsze pytanie i po 5.0 za dwa pozostałe. Z tego odpowiednio wyliczona została średnia ważona, która dała w ostatecznym rozrachunku 4.5. Całkiem nieźle, ale szedłem po 5.0 i byłem trochę zawiedziony mimo radości z dopięcia tego etapu w końcu.
To by było na tyle. W założeniu wpis miał być krótki i dość zwięzły, ale ta wizja powstała wczoraj - dziś pisząc już czułem to inaczej i zupełnie inaczej formowały się moje myśli. Mam nadzieję, że ktoś przez to przebrnął i coś może z tego wyciągnął sensownego. Jeśli ktoś chce więcej wiedzieć o mojej pracy lub prezentacji, to zapraszam do linka podanego już na samym początku - polecam bibliografię pracy, którą oczywiście można znaleźć na jej ostatniej stronie. That's all, folks. Do napisania wkrótce - muszę powiedzieć kilka słów o przyszłości tego bloga, co planuję zrobić szybko.
"There is no shame in defeat as long as the spirit is unconquered." - Fenix, Starcraft
Brak komentarzy:
Prześlij komentarz