Renifery ciągną sanie a Mikołaj święty…

SONY DSC

…siedzi w saniach i po drodze przegląda prezenty!

Zadziwiającym zbiegiem okoliczności przechwyciłam dwa listy do św. Mikołaja. W zasadzie przytrafia mi się to co roku, więc gdyby nie ich szczególna treść oraz fakt, że mój umysł  jest obecnie mocno skoncentrowany na nauce programowania, zapewne nie byłby to temat na niniejszego bloga. Ale ponieważ oba warunki zostały spełnione, między innymi lista życzeń była delikatnie rzecz ujmując odjechana w kosmos, w odwecie przyszła mi do głowy myśl programistyczna. Nie uda mi się jej niestety w tym roku wprowadzić w życie, piszę więc ku pamięci, żeby przygotować się na przyszłoroczne niespodzianki:)

Otóż na wyżej wymienione okoliczności, w celu uniknięcia nieuchronnych zaskoczeń, rozczarowań i ogólnego zdziwienia należy napisać program dla dzieci. Program ten, przez szereg inputów, będzie zbierać informacje na temat zachowania dziecka w minionym roku, przyznawać punktację (tak, również, a raczej głównie, punkty ujemne:)) po czym, na zakończenie, dziecko otrzyma informację jakiego prezentu może się spodziewać. I tak na przykład, za odpowiedź na pytanie ile razy w tym roku kot został wrzucony do wanny można by nabić sobie minus 50 punktów. Za każdego obciętego kociego wąsa minus 20. Za markowanie mycia zębów częściej niż dwa razy w tygodniu (włącznie z moczeniem szczoteczki dla niepoznaki) minus 30. Odkuć się będzie można na przykład za odgruzowywanie swojego pokoju – od 10 punktów na plus za systematyczne robienie przejścia od drzwi do okna żeby można było przewietrzyć do 50 za regularne wyrzucanie zgniłków i odpadków zza łóżka nim zaczną być odczuwalne przez sąsiadów. W efekcie, po podsumowaniu punktów, dziecko otrzyma informację co tak naprawdę powinno dostać od świętego Mikołaja, z najgorszą opcją – fotospacerem z mamą bladym świtem:)

Taka refleksja rodzicielsko – okołoświąteczna. List do św. Mikołaja w wersji beta. eMikołaj.pl:)

Słuchaj the Testing Goat!

SONY DSC

To zdjęcie powstało podczas rodzinnego spacerku ostatniego pogodnego dnia tej jesieni. Karmimy kózki w Karniowicach:) Uśmiałam się bo akcja natychmiast skojarzyła mi się z moją ostatnią aktywnością, dzięki której ćwiczę swoją systematyczność i dokładność, czyli zgłębianie tematu test-driven development (TDD). Posługują się w tym celu książką, którą poleciła mi Pewna Doświadczona w Temacie Osoba, czyli “Test-Driven Development with Python. Obey the Testing Goat: Using Django, Selenium and JavaScript”  autorstwa Harry’ego J. W. Percivala (https://www.obeythetestinggoat.com).  Póki co ucząc się skrupulatnie podążam za wskazówkami autora, ale gdy bardziej ogarnę temat będę się starała zastosować tę wiedzę do własnego, na początku choćby najmniejszego projektu.

Ogarnięcie tematu testów jest zazwyczaj juniorom zalecane. Faktycznie, bycie testerem wydaje się sensownym i co ważne realnym początkiem kariery w IT. Póki co starałam się o tym nie myśleć zbyt intensywnie, bo wizja ta, choć pragmatyczna, jest hm… mało urocza no i niezbyt nadaje się na motywację typu: “nie śpij po nocach, ogranicz wszystkie swoje aktywności do niezbędnego minimum, wysil wszystkie swoje komórki mózgowe, zwłaszcza te, o których istnieniu nie miałaś do tej pory pojęcia, zostań ninja w planowaniu czasu swojego i swojej rodziny, żyj w poczuciu, że robisz to kosztem najbliższych, bo w zamian… zostaniesz testerem:) Nie mam oczywiście nic przeciwko temu zajęciu, poza tym może na niektórych taka wizualizacja działa, ale na mnie po prostu nie. I kropka.

Ale zmobilizowałam się, ok, zobaczę o co w tym w ogóle chodzi. No i  oczywiście – zdziwiłam się. Po pierwsze tym, że tak naprawdę to też jest programowanie. I to w przypadku TDD konkretna filozofia programowania, która, o rety, do mnie trafia. Współgranie testów funkcjonalnych i jednostkowych, z których pierwsze patrzą z perspektywy użytkownika, dbają o to, by dać mu oczekiwaną wartość, a programiście pomagają w zaplanowaniu funkcjonalności aplikacji, z drugimi, które stopniowo pomagają te zamierzenia zrealizować – to ma sens! Podejście step-by-step przypomina zarządzanie w stylu agile, które zdążyło mi już przypaść do gustu i serca.

Ale, oczywiście, podążając za autorem wciąż się buntuję. No bo trzeba się wbić w straszny reżim, a ja tu jestem na etapie wymyślania sobie różnych projektów, dobierania do nich zagadnień, których w ten sposób się uczę lub ćwiczę (zatem im więcej na bieżąco pomysłów, tym lepiej), a tu nie, trzeba się trzymać tego co ściśle zaplanowane i ani kroku dalej. YAGNI! U mnie póki co wywołuje to ból, ale w komercyjnym świecie ma zapewne sens – nie powstaje niepotrzebny kod, więc nie marnuje się czasu, pieniędzy i energii programistów.  Zastanawia mnie jednak gdzie i jak jest określane to miejsce, w którym należy zastosować testy. W moim “podręczniku” testami objęte jest już zrobienie sobie kawy przed przystąpieniem do pracy:) Ale czy tak rzeczywiście ma być? Przecież pewne sprawy wydają się oczywiste, więc zajmowanie się nimi to jawna strata czasu, rzeczonych pieniędzy itp. Django na przykład ma, jak sądzę, dobrze opracowany system komunikowania błędów. Czy objęcie tych działań testami nie prowadzi do powstania zbędnych dubletów? I tak dalej…. Oj, wiele jeszcze do zrozumienia przede mną:) Cóż, wracam do książki słuchać meczenia mojej kózki:)

Tech Leaders – tu też zaczynam:)

SONY DSC

Mam to szczęście że zostałam uczestniczką trzeciej edycji Programu Tech Leaders https://techleaders.eu (za co jestem ogromnie wdzięczna) . Więc trzy, cztery, start – wczoraj odbyło się pierwsze spotkanie z mentorem. No i super, pogadaliśmy, doprecyzowaliśmy nasze cele i ustaliliśmy plan działań na najbliższy miesiąc.  Podstawowy cel jest jasny – chcę zacząć pracę w IT jako… junior backend developer.  Posłuchałam więc o doświadczeniach mojego mentora związanych z przyjmowaniem programistów do pracy oraz o przebiegu rozmów kwalifikacyjnych i procesów rekrutacyjnych. Dowiedziałam się co jest dobrze oceniane, jak należy się do rozmów przygotować i czego się spodziewać. Na przyszły tydzień mamy ambitny plan – zaczniemy od symulacji rozmowy rekrutacyjnej (wraz z częścią dotyczącą kodowania). A żeby nie było tak prosto 🙂 – będziemy gadać po angielsku. Ufff, już czuję ten stres, wcale nie symulowany…

Zabieram się do pracy. Wiem, że najbliższe cztery miesiące to będzie bardzo trudny ale i wartościowy czas. Mam przy tym fajne poczucie, że jestem na dobrej drodze, z nadanym właściwym kierunkiem. Jest dobrze.

 

No to zaczynamy!

SONY DSC

Zacznę może od wyjaśnienia nazwy tego bloga. Powody są póki co dwa, może jeszcze kiedyś coś wymyślę:) Otóż piszę sobie właśnie mały program w Pythonie, który roboczo nazwałam EarlyBird.

Z funkcjonalnego punktu widzenia umożliwia on skrzyknięcie się grupy osób na wspólne… no właśnie – oglądanie, podglądanie ptaków? Krótko mówiąc – bird-watching. Osoby zapisane do grupy otrzymują spersonalizowanego e-maila z informacją o ostatnio wprowadzonych do bazy danych obserwacjach, dokonanych w konkretnych hotspotach (źródło: eBird  https://confluence.cornell.edu/display/CLOISAPI/eBird+API+1.1) . Dodatkowo uczestnicy grupy mailingowej dowiadują się czy wśród najnowszych rekordów znajdują się gatunki, które grupa wytypowała jako swoje “must have”. Wiadomość zawiera również prognozę pogody (źródło: OpenWeatherMap https://openweathermap.org/api) i plan spotkania. Oczywiście, im dłużej z tym programem chodzę (bo nie zawsze myślę) tym więcej pomysłów i scenariuszy przychodzi mi do głowy. Więc do tego, mam nadzieję, jeszcze wrócę.

Ze strategicznego punktu widzenia uczę się w ten sposób ściągać dane z API (json, xml), mailingu, tłumaczenia pomysłu na kod i po prostu programowania. I to działa, zaczynam  na przykład powolutku rozumieć o co chodzi z tą hermetyzacją:)

I powód numer 2. Zdecydowana większość mojego kodu powstaje pomiędzy 4:00 a 6:30 rano, kiedy dom, dzieci, a ostatnio nawet kot jeszcze słodko i cicho śpią….