Przydatne drobiazgi (nie tylko do nauki)

13 Mar 2018 / admin

Życie składa się z drobiazgów, a niektóre drobiazgi ułatwiają życie. Dotyczy to nauki data science, a także w trakcie pracy "na serio". O jakich drobiazgach dziś opowiem?

  • Dobre IDE. IDE (integrated development environment) jest łącznikiem pomiędzy interpreterem (w przypadku Py i R) a użytkownikiem. Zawiera dobry edytor, który ładnie podświetla składnię. Mój ulubiony PyCharm podpowiada mi jak poprawić czytelność kodu, kontroluje indentację w kodzie (wiadomo jakie to ma znaczenie w Py!) i pokazuje jakie obiekty mam w pamięci. Do R polecam RStudio, ale uczciwie mówię -- nie próbowałem innych.
  • Cheat sheets. Ściągawki są dobre nie tylko na egzaminach ;) Takie ściągawki są fajne jako podręczny reference do kodu. Wiadomo, czasem zapomnimy, czasem potrzebujemy zrobić coś innego niż zwykle. Te z DataCamp są ok, ale w sieci jest wiele, każdy ma nieco inne potrzeby i gust, ale naprawdę można wybierać. Jeśli chcecie mieć jedną kartkę to do R używałem ofertowanej przez RStudio (tu). Ściagawki drukuję w kolorze na grubszym papierze (150 g). Można też wydrukować w formacie A3 i zawiesić jako plakat na ścianie.
  • Notepad++. Oczywiście do naszego kodu najlepiej używać edytora w naszym ulubionym IDE. Jeśli trzeba podejrzeć duży plik .txt czy .csv - lepiej użyć jakiegoś dobrego edytora czystego tekstu (nie mylić z Wordem itp.). Notepad++ przydaje się kiedy musimy skorzystać z kodu napisanego w innym języku, np. dodajemy zapytania SQL albo przepisujemy kod Java do naszego ulubionego Py lub R.

Jeśli znacie jakiś inny drobiazg, który ułatwia pracę (ale nie mówimy o ekpresie do kawy :) to proszę o maila, zamieszczę update cytując autora ciekawej propozycji.

Lektury dotyczące data science

15 Feb 2018 / admin

Dobre nawyki to jedno, ale skąd brać wiedzę? Jakis książki przeczytać? Najpierw czytać książki czy materiały w Internecie? Poczytać i zapisać się na szkolenia czy odwrotnie? O tym będzie ten fragment bloga.
Zacznijmy od kanonu literatury data science:

  • Trevor Hastie (i inni): An Introduction to Statistical Learning: with Applications in R - ta książka jest dobra na początek (wymaga podstawowej znajomości statystyki, ekonometrii i algebry liniowej), zobacz książkę, książka jest oficjalnie dostępna w wersji PDF
  • Trevor Hastie (i inni): The Elements of Statistical Learning: Data Mining, Inference, and Prediction, książka jest oficjalnie dostępna w wersji PDF. Ta książka jest bardziej techniczna, wymaga pewnego rozeznania w metodach, a notacja jest trudniejsza. Z drugiej strony oferuje dużo więcej niż tylko zapoznanie z metodami + kody do R.


Ci, którzy wybierają ścieżkę Pythona mają wiele darmowych materiałów do nauki tego języka. Na początek niezły kurs Pythona (podręcznik online + wideo) oferuje Google for Education. Kurs kilku podstawowych pakietów do DS (numpy, matplotlib) jest tutaj, ale to nie wszystko. Brakuje np. standardowo używanych pandas czy scikit-learn.

Dobre nawyki

15 Feb 2018 / admin

Znane przysłowie mówi, że czym skorupka za młodu nasiąknie... Data science dopiero zaczynam, ale pracuję z danymi już kilkanaście lat. W praktyce poznałem jak ważne są dobre nawyki:

  • Używanie właściwych narzędzi do właściwych celów. Przygotowanie środowiska pracy i koncepcji. Chyba nie wymaga komentarza - przygotuj się dobrze do analiz. Przemyśl metody, sprawdź wiele możliwości. Zastanów się z jakich danych chcesz skorzystać. Może ten projekt lepiej wykonam w Python niż R? Jak poradzę sobie z 60GB plikiem? Które dane nie są mi potrzebne? Jaki chcę output? Może lepiej gdy od razu pomyślę o wykresach - przyda mi się do raportu i prezentacji. Zrób raz, ale kompleksowo, to nie będziesz wracał do tematu piętnaście razy.
  • Zdrowa równowaga pomiędzy: "zrobię wszystko sam od podstaw" a "wezmę gotowca". Nie zawsze wszystko trzeba robić samodzielnie. Np. odwracanie macierzy jest doskonale oprogramowane w R a do tego wbudowana funkcja zadziała znacznie szybciej niż kod R (łatwo sprawdzić dodając dwa wektory "wbudowanym" operatorem sumy i pętlą). Przesada w drugą stronę oznacza, że bierzemy tylko to co jest gotowe. Szybko, tanio i wygodnie :) Niestety, w takim przypadku nie wiemy czy działa i w jaki sposób działa. Najprostszy przykład to mediana ze zbioru: 0, 1, 3, 7. Najczęściej wynik będzie średnią z 1 i 3, ale nie zawsze. A 10 percentyl z takich 4 obserwacji? Okazuje się, że jest kilka możliwości, jeśli zbytnio zaufasz gotowcom - otrzymasz niezrozumiały (nieoczekiwany) wynik.
  • Czystość kodu. To jest ważne, gdy nie jesteśmy jedynymi czytelnikami/autorami kodu. Nawet jeśli kod jest tylko dla nas, bałagan w kodzie spowoduje, że za rok nie będziemy rozumieli własnej twórczości. Dlatego zachowujmy kod czysty: (1) Nazwy zmiennych (a także klas, funkcji, plików...) odpowiadają temu co zawiera dana zmienna (czyli Page_adress, Sender_name zamiast x1, x2), (2) Używaj komentarzy! Rób to w trakcie pisania kodu, kiedy jeszcze doskonale wiesz po co tak napisałeś/aś, czemu służy dane zmienna. W komentarzach można też napisać o tym co jest jeszcze wymaga poprawy, uzupełnienia (np. "TODO: Dodaj sprawdzenie czy wektor jest niepusty."), (3) Nie komplikuj kodu. Potrójne list comprehension wygląda super mądrze, ale może w tym przypadku pętla (albo częściowo pętla) byłaby lepsza? Przydatne są konwencje kodowania a w dużych projektach wręcz wzorce projektowe.
  • Dokumentowanie własnej pracy. Czyli coś więcej niż komentarze (które robi się głównie dla siebie lub własnego teamu). Jeśli jesteś programistą w dużej firmie to zapewne będziesz musiał robić dokumentację na bieżąco (i będziesz z tego rozliczany!). A jeśli nikt Ci nie każe tego robić? Moim zdaniem staraj się robić krótkie notatki z tego co robisz. Może będziesz w przyszłości robił podobny projekt? Albo napiszesz o tym artykuł naukowy czy wpis na blogu? Prędzej czy później przekażesz komuś nie tylko wyniki ale i "wnętrze projektu" - wtedy będzie trzeba conieco opisać, ale po czasie zapomnisz większość swoich genialnych pomysłów. Poszerzasz team? Zamiast tłumaczyć wszystko od zera, możesz dać opis tego co już jest i na tej podstawie wdrażać kolegę/koleżankę do pracy. Trzeba zrobić instrukcję obsługi? Super, mam już większość w swoich notatkach. Chcesz pochwalić się tym już jest zrobione albo dostać wynagrodzenie za ukończony etap projektu? Nie ma problemu, bo zapisywałeś sobie na bieżąco co się działo :) Docenisz to szczególnie kiedy będziesz "z drugiej strony". Zdarza się, że dostajemy dane z fajnym opisem albo przejmujemy projekt z dokumentacją. W bardziej pesymistycznej (realistycznej?) opcji możesz dostać: opis zbyt lakoniczny żeby cokolwiek zrozumieć albo dokumentację w zupełnie nie znanym Ci języku.

Oczywiście to są tylko zajawki, a każdy z tych punktów można rozwinąć, ale tak naprawdę najlepiej spróbować zastosować w praktyce (spróbuj, zobaczy że oszczędzi to trochę czasu i nerwów).
Wreszcie na koniec dwie krótkie refleksje. Same obliczenia to tylko 10% pracy. Większość czasu zajmie Ci zrozumienie danych, wstępna obróbka (usunięcie braków danych, filtracja błędów technicznych - w miejscu gdzie oczekujemy liczby znajduje się tekst albo w bazie brakuje pewnych informacji, weryfikacja logiczna danych - obejrzyj dane, popatrz czy nie ma tam np. ujemnych zarobków albo czy średnia liczba dzieci w gospodarstwie domowym nie odbiega za bardzo od tego co wiemy z ogólnodostępnych danych demograficznych - jeśli tak to dlaczego?, ograniczenie zbioru). W przypadku data science dochodzą jeszcze techniczne wyzwania związane z bardzo dużymi zbiorami danych. Być może będzie trzeba zainstalować jakiś serwer bazodanowy albo zastosować jakiś szybszy algorytm? No, a na koniec trzeba to jeszcze opisać i zrobić prezentację.Teoria też jest ważna. Wszyscy mówią teraz, że studia mają uczyć praktyki, oczekujemy praktycznych rad czy wręcz gotowców. Uwierzcie mi, jestem praktykiem. Ale z czystego lenistwa warto zapoznać się z teorią - przykłady już wkrótce na blogu.



1 2 następny ... koniec