Projekt “Open”

PICT0528

No to czas na powrót do codzienności po świątecznym obżarstwie i relaksie! Taki żarcik, bo na szczęście wyjatkowego obżarstwa nie zaznałam, a relaks wyłącznie tego szczególnego typu kiedy człowiek wraca po świętach do pracy i czuje przyjemny spokój i ciszę:)  Choć faktycznie tym razem był powód do świętowania, bo mój kręgosłup znów pozwala mi na urocze tete-a-tete z laptopem. Swoją drogą, żartów nie ma, trzeba się faktycznie pilnować i uwalniać od złych nawyków, bo przydługie posiady z kompem są po prostu groźne. I tu filmik ku własnej przestrodze.

Ale do rzeczy, czyli mały update. Ostrożnie przymierzam się do tematu kontrybuowania w projektach open source’owych. Ostrożnie, bo moją czujność wzmogły reakcje Ludzi Dobrze Znających Się Na Rzeczy – mówię na co się porywam i widzę w odpowiedzi uważny a jednocześnie pełen troski i niedowierzania wzrok. Gdyby umiał mówić pewnie byłoby to coś w rodzaju “kobieto, ach na co ci to, kompoty warz!” I komentarz, tym razem słowny: “wiesz, tylko nie zrażaj się, bo to takie… specyficzne jest”.

Aby więc przestać się czuć w tym temacie jak moja koleżanka na obrazku, zabrałam się do tematu metodycznie. Po pierwsze, podążając za ideą “first-timers-only” znalazłam potencjalne źródło problemów do rozwiązania.  37 issues do przeglądnięcia i stwierdzenia czy na tym etapie w którymkolwiek z nich mam coś do powiedzenia. Na chwile zwątpienia mam w zanadrzu prezentację Kenta C. Doddsa,  który bardzo fajnie działa na rzecz oswajania zielonych w temacie open source z procesem PR. Dla równowagi, uświadamia też właścicieli/koorynatorów projektów jak ważne jest ułatwianie juniorom zdobywania pierwszych szlifów oraz mocno promuje dobre praktyki w tym zakresie. Po drugie skorzystałam z zasobów pana Kenta przerabiając krótki tutorial dotyczący procesu PR (ach czemuż, czemuż pan Kent zadaje się głównie z JavaScriptem? Pewnie nie słyszał o Pythonie). Przy okazji, doceniłam side-effect swojego bootcampu, gdzie zarówno prework, jak i poszczególne egzaminy odbywały się z wykorzystaniem GitHuba i pull requestów. Gdyby jednak zaistaniała potrzeba, sam GitHub oferuje oczywiście kompletną informację “How to contribute to Open Source”. A, mam jeszcze jedno zestawienie projektów, które są otwarte na nowicjuszy. Może nie tak uroczo obrane z ości jak pierwsze źródło, ale też wygląda nieźle. Zawiera zbiory (w podziale na języki) projektów wybranych pod kątem “awsome for beginners”.  W tej sytuacji no excuses – teoria opanowana, gdybym, dajmy na to, chciała coś pull-requestować to przynajmniej formalnych głupot nie narobię. Chyba. Więc może następny wpis to wreszcie będzie jakaś success story. Muszę tylko znaleźć podobną skalę trudności issue co pan Kent będący młodym programistą. Jak wspominał w swojej prezentacji, jego pierwsza kontrybucja polegała na usunięciu literówki popełnionej w komentarzu. Ale w Javie:)

A gdyby tak prosto nie było, znalazłam bardziej uchwytną formę odwdzięczenia się społeczności za dotychczas doznane dobro, czyli tłumaczenie kursów udostępnionych na Courserze.

Hello GitHub!

DSC05713

Kilka dni po ustaleniach dotyczących zarządzania czasem i zadaniami mam następujące wnioski:

  1. pomysł sam w sobie nie jest głupi, co najwyżej patrz punkt 2,
  2. na ogół nie jestem w stanie wygospodarować tyle czasu ile bym chciała / sobie założyła,
  3. nie zmienia to faktu że punkt 1,
  4. jeśli nie mam wystarczającej ilości czasu, to raczej należy zredukować okres przeznaczony pierwotnie na poszczególne obszary niż rezygnować z któregoś z nich,
  5. oznacza to jeszcze bardziej precyzyjne zarządzanie, bo trzeba przewidzieć, że  danego dnia należy przejść w tryb metasamoograniczenia:),
  6.  brakuje mi narzędzi.

I a propos punktu 6 – potrzebowałabym aplikacji, która umożliwiałaby mi, powiedzmy wieczorem, zaplanować  kolejny dzień. Powinnam mieć możlwiość ustalenia przedziałów czasowych, które mogę przeznaczyć na Projekt Junior (zazwyczaj 4 – 6:30 rano oraz dwie / trzy luźniejsze półgodziny w ciągu dnia) tak, żeby zmieścić się w koncepcji 5 x 45 (30) minut. Poszczególnym przydziałom czasowym mogłabym przyporządkować temat / źródło z wcześniej wprowadzonej listy, skojarzonej z poszczególnym obszarem. Na kolejne dni mogłabym dostawać podpowiedzi typu “kontunuuj temat”, ale też móc wybrać coś innego z listy (ewentualnie ją uzupełnić). Ostatnią porcję czasu w ciągu dnia przeznaczałabym na szybkie podsumowanie – odznaczanie co udało się zrobić, a co niestety musi przejść na kolejny dzień. Taka możliwość, oprócz funkcji motywacyjnej fajnie porządkowałaby pracę i dawała dobry feedback co udało się dotychczas zrobić i w jakim jestem miejscu w poszczególnych tematach. A, i jeszcze na sam koniec planowanie kolejnego dnia.

No i pointa – pewnie taki program istnieje, a ja o tym nie wiem:) Mam nadzieję, że nie występuje tu syndrom zakupu butów – zwykle na tyle dokładnie wiem czego potrzebuję, a raczej czego bym chciała, że nigdy nie jestem w stanie właśnie tego kupić:) Ale, tu jest rozwiązanie – jeśli takiego narzędzia do wspierania rozwoju nie ma, to może należałoby go napisać? Szewcem nie będę, programistką – wannabe!

Btw – czy to już skrzywienie jeszcze-nie-zawodowe? Ogarniając przedświątecznie szpargały mojej młodzieży, natknąwszy się na szpeje z wizerunkiem kocicy zwanej Hello Kitty doznałam skojarzenia z GitHubem:) No w sumie…:))

Piąty element

SONY DSC

Czas na przedświąteczne porządki. Przynajmniej wirtualne, bo na tradycyjne chwilowo nie pozwala mi obniżenie przestrzeni międzykręgowych na szczycie kyphozy piersiowej:) Przyglądnęłam się krytycznie moim chaotycznym zapisom w Trello i postanowiłam nad nimi nieco zapanować. Był też już najwyższy czas na ponowne zdefiniowanie bliższych i dalszych celów, a tym samym najważniejszych aktywności i zapanowanie nad kalendarzem tak, by na każdy z tych obszarów przeznaczać systematycznie odpowiednią ilość czasu. Nie brzmi to może zbyt uroczo, ale czego się nie robi żeby zostać juniorem:) Zwłaszcza, jeśli na ten cel można realnie przeznaczyć maksymalnie 3 – 4 godziny dziennie.

Pierwszy obszar to projekty / zadania, nad którymi obecnie pracuję. Aktualnie są to zadanka algorytmiczne, TDD i projekty umieszczone na GitHubie doprowadzone do pewnego etapu, które chcę jeszcze rozwinąć. Mam na to pomysły, za to wiecznie nie mam czasu. Postanowiłam sobie, że nie porzucę ich tak brutalnie, ale regularnie będę do nich co jakiś czas wracać. Priorytet może nie najwyższy, ale wciąż w grze. W kolejce czeka zabranie się do kontrybuowania w projektach open source’owych, zacznę od wyszukiwania bugów w projektach polecanych dla początkujących typu https://github.com/MunGell/awesome-for-beginners. Jest szansa, że sprawa przyspieszy w ramach aktywności nr 5.

Drugi obszar to rozwijanie moich ekhm, programistycznych horyzontów. W tej grupie mieszczą się, patrzę na moją podręczną półeczkę, min. “Głowa do liczb” Barbary Oakley (do tej książki jeszcze wrócę, bo jest zachwycająco opytmistyczna), świeży a już bestseller “Zawód Programista” Macieja Aniserowicza no i nadambitne (oczywiście dla mnie) “Zrozumieć programowanie” Gynvaela Coldwinda. Poza półeczką aktualnie mam jeszcze “na podorędziu” kurs o algorytmach Khan Academy https://pl.khanacademy.org/computing/computer-science/algorithms/binary-search/a/implementing-binary-search-of-an-array, podcasty i vlog DevStyle https://devstyle.pl oraz fascynujący kurs “Internet History, Technology and Security” https://www.coursera.org/learn/internet-history/home/welcome.

Obszar trzeci to kilka kursów internetowych, które mnie wiecznie kuszą, min. na Pluralsight https://app.pluralsight.com/paths/skills, Udemy https://www.udemy.com/the-python-mega-course czy Data Camp https://www.datacamp.com/courses/intro-to-python-for-data-science.  Oprócz świetnie podanej piguły wiedzy mają jeszcze tę wartość, że przy okazji można podszkolić angielski.

Czwarty obszar, na który chcę wygospodarować sobie czas to wreszcie! kontakty międzyludzkie, czyli spotkania, meetupy i inne okazje do fajnego networkingu. I niniejszy blog:)

Piąta sprawa, obecnie z najbardziej napiętym grafikiem, to praca w ramach Tech Leaders.

Idea jest taka, żeby codziennie przeznaczyć 45 minut na każdy z tych obszarów. Na co dokładnie – to zależy. Od potrzeby, ilości czasu i nastroju. Tu zostawiam sobie zdrową swobodę. I będzie progres:)

Jak mierzyć poziom stresu indeksem Hirscha

SONY DSC

Niestety, skutecznie… Wracam do mojej pierwszej mockowej rozmowy rekrutacyjnej, na której miałam  wątpliwą (w moim pierwszym odczuciu) przyjemność zaznajomić się z ideą niejakiego pana Jorgego E. Hirscha. Hmmm… Zrozumienie tej koncepcji,  ułożenie sobie w głowie dokąd zmierzam i jak do tego dojść oraz przełożenie pseudokodu na składnię Pythona w warunkach stresu i pod presją czasu okazało się naprawdę niełatwe.  Poległam na ostatnim etapie, zabrakło mi czasu i umiejętności utrzymania koncentracji.  Ale uff, o dziwo mój mentor nie był bardzo niezadowolony, uznał, że jeśli ktoś dobrze myśli, to uzyskanie biegłości w kwestiach technicznych jest kwestią czasu. Więc jednak mały plus. No i angielski na plusie, bo w tym zakresie nie stwierdzilśmy trudności komunikacyjnych:)

Ja jednak byłam nieco rozczarowana, zaczęłam więc zgłębiać temat i oprócz standardowego definiowania problemu (np. https://en.wikipedia.org/wiki/H-index) znalazłam ciekawe rozwiązanie, oparte na relacji pomiędzy indeksem (w sensie pozycji na liście) a liczbą umieszczoną na liście pod tym indeksem (http://subjectguides.uwaterloo.ca/calculate-academic-footprint/YourHIndex).  Okazuje się, że indeks można łatwo ustalić poprzez znalezienie pozycji na liście, która swoją wartością dorówna lub przekroczy wartość pod nią zapisaną. Zestawienie tych podejść może wyglądać następująco (dwa pierwsze: podejście “indeksowe”, ostatnie: szukanie właściwych elementów na liście). Wszystkie zakładają, że elementy na liście są ułożone w porządku malejącym oraz nie mają pojącia czym jest złożoność obliczeniowa:).

class Solution:

    def hirsch_index(self, lst):
        result = []
        for i in range(len(lst)):
            if i >= lst[i]:
                result.append(i)
                break
        return result[0]


    def hirsch_index2(self, lst):
        i = 1
        while i < lst[i]:
            i += 1
        return i


    def hirsch_index3(self, lst):        
        ind = 1
        while len([number for number in lst if number >= ind]) - 1 >= ind:
            ind += 1
        return ind


s = Solution()
print(s.hirsch_index3([28, 22, 20, 6, 5, 4]))

Patrzę na to podejście i myślę sobie, że jest jednak problem. Załóżmy, że mamy do czynienia z wybitnym, rzadko publikującym naukowcem, którego wszystkie publikacje mają większą ilość cytacji niż ilość opublikowanych artykułów. I co wtedy? A może taka sytuacja po prostu nie może się zdarzyć w rzeczywistym świecie? Idę czytać…

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.