Ładować 'zachłannie', czy 'leniwie'?
JOINS vs INCLUDES!

Większość skomplikowanych aplikacji opiera się o relacyjne bazy danych i wymaga ciągłego wydobywania powiązanych ze sobą informacji. Railsy ułatwiają te operacje, udostępniając moduł ActiveRecord, dysponujący wieloma przydatnymi metodami. Żeby jednak w pełni wykorzystywać ich możliwości - należy je dobrze rozumieć i znać ich zastosowania.
Warto na przykład wiedzieć czym różni się joins od includes.


Kiedy którym się posłużyć? Najkrótsza, ale najprawdziwsza odpowiedź brzmi:

optimal use cases - wszystko zależy od tego jak i jakie dane chcemy wykorzystać

Błędnym zastosowaniem ryzykujemy

  • performance (słynne N+1 queries)
  • czasem niepoprawnymi danymi (niezgodnymi z naszymi oczekiwaniami)
  • czy nawet zderzeniem z errorem

Ale zacznijmy od początku - skąd tytuł nawiązujący do zachłanności czy lenistwa?

Eager loading VS Lazy loading

Niezależnie od frameworka, czy nawet języka programowania, jeżeli posługujemy się ORM (Object-relational mapping ) możemy mówić o dwóch koncepcjach:

Eager loading

  • …tłumaczone na język polski jako ładowanie zachłanne, ładowanie chciwe
  • related, child objects are loaded automatically with its parent object
  • jest zachłanne, ponieważ polega na ładowaniu od razu wszystkiego co jest możliwe, maksimum informacji na temat obiektów powiązanych z naszym bazowym
  • załadujemy zarówno dane z tabeli parent jak i dane wynikające z relationships

Lazy loading

  • …tłumaczone jako ładowanie leniwe
  • related objects are not loaded until it is required
  • w odróżnieniu od eager loading - tutaj ładujemy minimum informacji, sięgając po dodatkowe dopiero, kiedy są potrzebne, kiedy jawnie po nie sięgamy (wykonane zostanie wtedy dodatkowe zapytanie)
  • załadujemy jedynie dane z tabeli parent

Na pierwszy rzut oka lepszym rozwiązaniem wydaje się lazy loading - po co ładować wszystko na raz, dopóki tego nie potrzebujemy?

I wtedy na scenę wchodzi performance, ale o nim - już w kontekście Railsów.

JOINS

Zacznijmy od joins, bo jest z nim nieco łatwiejsza sprawa.

@users = User.joins(:clients).where('clients.country = ?', 'Poland')
  • wiążemy z nim lazy loading
  • ładuje do pamięci dane dotyczące użytkowników na podstawie relacji z klientami
  • nie ładuje natomiast danych dotyczących samych klientów
  • próba wydobycia danych dot. klientów - będzie wiązała się z dodatkowym zapytaniem (#smutnyPerformance #N+1queries)
 User.joins(:clients).where('clients.country = ?', 'Poland').each { |u| u.clients.map(&:country) }; nil
  User Load (...ms)  SELECT "users".* FROM "users" INNER JOIN "clients" ON "clients"."user_id" = "users"."id" WHERE (clients.country = 'Polska')
  Client Load (7.2ms)  SELECT "clients".* FROM "clients" WHERE "clients"."user_id" = $1  [["user_id", ...]]
  Client Load (0.6ms)  SELECT "clients".* FROM "clients" WHERE "clients"."user_id" = $1  [["user_id", ...]]
  Client Load (0.5ms)  SELECT "clients".* FROM "clients" WHERE "clients"."user_id" = $1  [["user_id",  ...]]
  Client Load (0.5ms)  SELECT "clients".* FROM "clients" WHERE "clients"."user_id" = $1  [["user_id", ...]]
  Client Load (0.5ms)  SELECT "clients".* FROM "clients" WHERE "clients"."user_id" = $1  [["user_id", ...]]
  Client Load (0.5ms)  SELECT "clients".* FROM "clients" WHERE "clients"."user_id" = $1  [["user_id", ...]]
  Client Load (0.4ms)  SELECT "clients".* FROM "clients" WHERE "clients"."user_id" = $1  [["user_id", ...]]
  Client Load (0.4ms)  SELECT "clients".* FROM "clients" WHERE "clients"."user_id" = $1  [["user_id", ...]]
  Client Load (0.4ms)  SELECT "clients".* FROM "clients" WHERE "clients"."user_id" = $1  [["user_id", ...]]
  Client Load (0.7ms)  SELECT "clients".* FROM "clients" WHERE "clients"."user_id" = $1  [["user_id", ...]]
  Client Load (1.9ms)  SELECT "clients".* FROM "clients" WHERE "clients"."user_id" = $1  [["user_id", ...]]
  Client Load (2.2ms)  SELECT "clients".* FROM "clients" WHERE "clients"."user_id" = $1  [["user_id", ...]]
  Client Load (0.6ms)  SELECT "clients".* FROM "clients" WHERE "clients"."user_id" = $1  [["user_id", ...]]
  Client Load (0.5ms)  SELECT "clients".* FROM "clients" WHERE "clients"."user_id" = $1  [["user_id", ...]]
  ....
  • warto zwrócić uwagę, że posługuje się domyślnie INNER JOIN-em
User.joins(:clients).where('clients.country = ?', 'Poland').to_sql
 => "SELECT \"users\".* FROM \"users\" INNER JOIN \"clients\" ON \"clients\".\"user_id\" = \"users\".\"id\" WHERE (clients.country = 'Poland')"
=> generalnie joins będziemy używali do przefiltrowania wyników kiedy nie korzystamy z rekordów relacji


INCLUDES

…jak można się domyślić stoi po drugiej stronie barykady

@users = User.includes(:clients)
  • tutaj mówimy o eager loading
  • obie tabele ładowane są do pamięci
  • w ten sposób korzystanie z danych klientów - nie wywoła dodatkowego zapytania
User.includes(:clients).where('clients.country = ?', 'Poland').references(:clients).each { |u| u.clients.map(&:country) }; nil
  SQL (...ms)  SELECT "users"."id" AS t0_r0, "users"."imie" AS t0_r1, "users"."nazwisko" AS t0_r2, "users"."email" AS t0_r3, "users"."nazwa_uzytkownika" AS t0_r4, "users"."haslo" AS t0_r5, (...) "clients"."id" AS t1_r0, "clients"."user_id" AS t1_r1, "clients"."nazwa_firmy" AS t1_r2, "clients"."ulica" AS t1_r3, "clients"."miejscowosc" AS t1_r4, "clients"."kod_pocztowy" AS t1_r5, "clients"."nip" AS t1_r6, "clients"."numer_telefonu" AS t1_r7, (...) "clients"."touched_at" AS t1_r28 FROM "users" LEFT OUTER JOIN "clients" ON "clients"."user_id" = "users"."id" WHERE (clients.country = 'Polska')
  • warto wiedzieć, że dane mogą być ładowane na dwa sposoby:
    • jako osobne zapytania (separate queries)
    • przy pomocy jednego zapytania (domyślnie: w oparciu o LEFT OUTER JOIN)
  • o tym który ‘wybrać’ decyduje nie performance ale postać zapytania
  • aby wymusić single query (i tym samym LEFT OUTER JOIN) - można wykorzystać eager_load
User.includes(:clients).eager_load(:clients)


INCLUDES + WHERE

Dlaczego dostało własną sekcję?
Otóż okazuje się, że może przysporzyć kłopotów. Próba przefiltrowania użytkowników przy wykorzystaniu includes

@users = User.includes(:clients).where('clients.country = ?', 'Poland')

ActiveRecord::StatementInvalid: PG::UndefinedTable: ERROR:  missing FROM-clause entry for table "clients"....

…może nie skończyć się najlepiej.

Aby móc ‘postawić warunki’, wykorzystując includes możemy skorzystać z references Należy jednak pamiętać, że includes jako argument przyjmuje nazwę relacji określonej w modelu, references zaś - nazwę tabeli

@users = User.includes(:clients).where('clients.country = ?', 'Poland').references(:clients)

…lub też skorzystać z innej składni, której efektem będzie takie samo zapytanie SQL

@users = User.includes(:clients).where(clients: { country: 'Poland'})


TL;DR

  • wybór joins czy includes zależy od kontekstu (posługiwania się danymi)
  • lazy loading - ładowanie bez danych obietków powiązanych
  • eager loading - ładowanie również danych obietków powiązanych
  • warto zaglądać w SQL generowany przez wywołania metod AR (to_sql)
  • warto przyjrzeć się narzędziu monitorującemu zapytania wykorzystywane w naszej aplikacji: https://scoutapp.com/devtrace
JOINS INCLUDES
Kiedy warto?
Filtrowanie wyników na podstawie powiązanych
Kiedy warto?
Wykorzystanie danych rekordów powiązanych
lazy loading eager loading
tylko parent data parent + relationships data
domyślnie: INNER JOIN domyślnie: LEFT OUTER JOIN
ryzyko N+1 queries przy odwołaniu do danych powiązanych należy uważać przy filtrowaniu (grozi error)
  ładuje za pomocą single query albo separate queries


Ciekawostka do refleksji

Na początku wspomniałam o ryzyku uzyskania innych danych niż się spodziewamy w zależności od wykorzystanego zapytania.
Dlatego zostawiam do samodzielnego przemyślenia skąd takie różnice w - na pozór - identycznych zapytaniach:

2.4.0 :001 > User.includes(:clients).where(clients: { email: nil }).count
(3.0ms)  SELECT COUNT(DISTINCT "users"."id") FROM "users" LEFT OUTER JOIN "clients" ON "clients"."user_id" = "users"."id" WHERE "clients"."email" IS NULL
 => 158
2.4.0 :002 > User.joins(:clients).where(clients: { email: nil }).count
   (1.0ms)  SELECT COUNT(*) FROM "users" INNER JOIN "clients" ON "clients"."user_id" = "users"."id" WHERE "clients"."email" IS NULL
 => 47
2.4.0 :003 > User.includes(:clients).where('clients.email = ?', nil).references(:clients).count
   (1.0ms)  SELECT COUNT(DISTINCT "users"."id") FROM "users" LEFT OUTER JOIN "clients" ON "clients"."user_id" = "users"."id" WHERE (clients.email = NULL)
 => 0

5 wtyczek Vima, bez których się nie obędziesz

vim-main2

Wybrałem dla was 5 wtyczek, które zmieniają Vima w jeszcze lepszy edytor tekstowy oraz przybliżają go do pełnoprawnego IDE.

1. Vim-projectionist

Największą zaletą projectionist jest szybkie przełączanie pomiędzy plikiem bazowym, a jego, wcześniej zdefiniowanym, plikiem alternatywnym (“alternate”), który możemy zdefiniować dla każdego języka osobno:

{
  "src/main/java/*.java": {"alternate": "src/test/java/{}.java"},
  "src/test/java/*.java": {"alternate": "src/main/java/{}.java"}
}

Mając tak zdefiniowane pliki alternatywne i po wpisaniu :A, gdy znajdujemy się w modelu, zostanie otwarty plik zawierający jego testy. Istnieje kilka odpowiedników komendy :A - różnią się one miejscem, w którym ma zostać otwarty plik alternatywny:

  • obecnym oknie (:A)
  • obecny oknie, ale w podziale horyzontalnym (:AS)
  • obecnym oknie, ale w wertykalnym podziale okna (:AV)
  • w nowej zakładce (:AT)

Oprócz “alternate”, możemy zdefiniować także szkielet jaki ma być wstawiony do każdego nowego pliku w podanym folderze.

{
  "app/models/*.rb": {
    "template": [
      "class \{} < ApplicationRecord",
      "end"
    ]
  }
}

Przy tworzeniu szkieletów możemy wykorzystać wbudowane funkcje, które odpowiednio zmodyfikują wpisany tekst:

{snakecase}
{dirname}
{underscore}
{backslash}
{camelcase}
{colons}
{hyphenate}
{blank}
{uppercase}
{capitalize} --- alias jako \\{}
{basename}
{dot}
{singular}
{plural}
{open}
{close}

2. Vim-test

Testy można uruchamiać na wiele sposobów: począwszy od ręcznego uruchamiania wszystkich, pojedynczych plików testowych, po automatyczne (przy użyciu narzędzi śledzących zmiany w plikach np. guard).

Wtyczka vim-test pozwala na szybkie uruchamianie testów z poziomu Vima. Posiada wsparcie dla większości języków programowania. Wynik testow wyświetlany jest wewnątrz edytora więc nie musimy się przełączać między oknami. Cały czas pozostajemy w Vimie, co umożliwia nam szybkie poruszanie się, kopiowanie oraz wyszukiwanie w wyniku testów.

vim-test-select

Testy możemy uruchamiać w zależności od pożądanego zakresu, co daje nam ogromną kontrolę nad wykonywanymi testami oraz znacznie przyspiesza ich wykonywanie. Poniżej przedstawiam zakresy wraz z przykładowymi skrótami klawiszowymi:

nmap <silent> <leader>t :TestNearest<CR> " Uruchamia najbliższy
test względem aktualnej pozycji w otwartym pliku

nmap <silent> <leader>T :TestFile<CR> " Uruchamia cały plik
testowy, który mamy aktualnie otwarty

nmap <silent> <leader>a :TestSuite<CR> " Uruchamia wszystkie pliki
testowe

nmap <silent> <leader>l :TestLast<CR> " Uruchamia ostatni test

nmap <silent> <leader>g :TestVisit<CR> " Otwiera ostatni plik
testowy, który mieliśmy otwarty np. przed serią poprawek w kodzie
projektu.

Wtyczka umożliwia również zdefiniowanie własnej domyślnej komendy uruchomieniowej testów, dzięki czemu z łatwością uruchomimy je np. na dockerowym kontenerze.

let test#ruby#rspec#executable = 'docker-compose -f ../compose.yml run container_name rspec'

Kolejnym przydatnym ustawieniem jest możliwość zmiany strategii, jeśli nie chcemy, aby wynik testów pojawiał się wewnątrz edytora. Można zamienić ją na np. vtr oraz zainstalowanie pluginu vim-tmux-runner co spowoduje wyświetlenie testów w małym oknie Tmuxa.

let test#strategy = { 'suite': 'vtr' }

Strategie możemy ustawiać osobno dla każdego z zakresów wykonywanych testów (najbliższy, całość itp.). Dodatkowo vim-test przy pomocy pluginu projectionist pozwala na uruchamianie testów z poziomu plików nietestowych ustawionych jako pliki alternatywne.

3. Vim-rails

Vim-rails może okazać się dla was niezbędną wtyczką, jeśli jesteście deweloperami Ruby i korzystacie z frameworka Ruby on Rails. Istnieją odpowiedniki tego pluginu dla innych frameworków np. vim-phoenix które maja zbliżoną funkcjonalność.

Podstawową funkcjonalnością jest integracja z projectionist pod kątem frameworka, co daje nam możliwość skorzystania z pomocnych komend, takich jak:

  • Emodel nazwa_pliku - edycja modelu o podanej nazwie

  • Eview nazwa_pliku - edycja widoku o podanej nazwie

  • Econtroller nazwa_pliku - edycja kontrolera o podanej nazwie

Powyższe komendy mają swoje odpowiedniki w zależności od sposobu, w jaki ma zostać otwarty plik:

  • ! - plik o podanej nazwie zostanie utworzony, gdy nie istnieje na dysku. Dodatkowo, będzie zawierał szkielet, jeśli jest dla niego zdefiniowany. Znak ten należy dodać na końcu nazwy pliku.

  • S - plik zostanie otwarty horyzontalnym podziale okna, gdy zastąpimy E w nazwie komendy.

  • V - plik zostanie otwarty wertykalnym podziale okna, gdy zastąpimy E w nazwie komendy.

  • T - plik zostanie otwarty w nowej zakładce, gdy zastąpimy E w nazwie komendy.

Wtyczka integruje również Railsową konsole, generatory oraz serwer, co pozwala nam na pozostanie wewnątrz Vima i wykonywanie praktycznie wszystkich czynności związanych z rozwojem projektu.

  • Rake - pozwala na uruchamianie zadań rake

  • Rails - opakowuje komendę rails

  • Generate - krótsza forma Rails generate

  • Rails console - uruchamia konsole Rails

  • Rails server - uruchamia serwer aplikacji

Bardzo przydatną funkcjonalnością, jaką dostarcza wtyczka jest :Extract. Po zaznaczeniu bloku tekstu oraz wywołaniu tej komendy, zostajemy przeniesieni do nowego pliku z wydzielonym kodem. Zostaje on również automatycznie dołączony do pliku bazowego. W ten sposób możemy wydzielać concerny dla modeli i controllerów oraz partiale dla widoków.

4. Vim-surround

Surround to wtyczka do szybkiego usuwania, modyfikowania, dodawania otaczających tekst nawiasów, tagów xml i html oraz apostrofów.

5. Fzf.vim

Aby wygodnie wyszukiwać i otwierać pliki z poziomu Vima możemy, użyć popularnego pluginu ctrlp, który spełnia swoje zadanie, lecz wymaga cache’owania i odświeżania zaindeksowanych plików. Czasami potrafi działać powoli, a znalezienie konkretnego pliku nie zawsze jest łatwe, zwłaszcza, jeśli mamy wiele plików o tej samej nazwie lub w bardzo zagnieżdżonych folderach.

Lekarstwem na wszystkie bolączki jest plugin fzf, który wykorzystuje fuzzy finder fzf napisany w Go. Zaletą fzf jest błyskawiczne indeksowanie plików, co eliminuje potrzebę cache’owania. Autor przygotował wiele przydatnych, gotowych funkcji oraz api do integracji fzf z własnymi funkcjami. Każda z funkcji zwraca wynik, w którym to możemy wyszukiwać za pomocą fzf fuzzy finder.

Oto lista najbardziej przydatnych:

  • Files - zwraca listę wszystkich plików w projekcie
  • GFiles - zwraca listę plików znalezionych z użyciem git ls-files
  • Ag - zwraca listę plików wraz z numerem linii oraz jej zawartością, w których występuje wyszukiwana fraza
  • Lines - zwraca listę linii ze wszystkich plików znajdujących się w buforze
  • BLines - zwraca listę linii w aktualnym pliku
  • Commits - lista commitów wraz z podglądem zmian
  • BCommits - lista commitów dla aktualnego pliku wraz z podglądem zmian

Dodatkowo, każdą z funkcji można uruchomić dodając na końcu !, co spowoduje otwarcie wyniku w pełnym oknie, ignorując nasze wcześniejsze ustawienia rozmiaru okna.

Po wiecej pluginów wraz z ich ustawieniami oraz inne przydatne konfiguracje (tmux, fish shell), odsyłam do moich dotfiles, które umieściłem na githubie.

W kolejnym artykule, Kazik przedstawi 5 wtyczek, których używa na co dzień.

---

https://github.com/daktyr/dotfiles/blob/master/nvim/init.vim

https://github.com/junegunn/fzf

https://github.com/junegunn/fzf.vim

https://github.com/tpope/vim-projectionist

https://github.com/tpope/vim-surround

https://github.com/tpope/vim-rails

https://github.com/janko-m/vim-test

https://github.com/guard/guard

https://github.com/ctrlpvim/ctrlp.vim

https://github.com/avdgaag/vim-phoenix

#Euruko2017 - How to make it as a junior developer and stay sane

Rozmowa i opinie po prezentacji „How to make it as a junior developer and stay sane”



Dima Boyko (Software Engineer, inFakt.pl): Słuchaliśmy teraz prezentacji „How to make it as a junior dev and stay sane” i widzę, że też masz napisane Junior Developer, czyli to samo.

Agnieszka Abgaro Zachariasiewicz (Ruby developer, inFakt.pl): Dokładnie.

Dima: Czy historia tej prezentacji jest podobna do Twojej?

Agnieszka: Nie wiem, czy podobna, ale na pewno było tam dużo ważnych wskazówek właśnie z perspektywy pozycji juniorskiej według mnie. Dziewczyna opowiadała o bardzo ciekawych rzeczach. O takich, żeby na przykład nie bać się zadawać pytania, nawet jeżeli są one trywialne dla osób, które siedzą koło Ciebie.

Powiedzmy jesteś sobie juniorem, a koło Ciebie siedzą sami seniorzy. Masz zrobić jakieś zadanie, z którym masz problem i nie wiesz jak to zrobić. Wydaje Ci się, że głupio jest podejść i zapytać, a właśnie ona zachęcała do tego, że nie ma głupich pytań i trzeba próbować.

I nie chodzi o to, żeby postępować według jakichś schematów, tylko trzeba po prostu próbować i właśnie „failować” (że tak powiem - tak jak było to tam ujęte) i tak możesz dojść do perfekcji.

Dima: No właśnie było takie hasło, że nie ma głupich pytań. Czy zgadzasz się z tym? Czy jednak widziałaś sytuacje, że pytania mogą być głupie?

Agnieszka: Czasem się tak wydaje. Myślę, że bardzo często się tak wydaje, że pytania, które przychodzą do głowy są głupie i trywialne i głupio jest z nimi pójść, ale raczej staram się chodzić i pytać, bo faktycznie to pomaga, a developerzy są bardzo otwarci i zawsze pomagają.

Także to też na tym polega, że jeden drugiemu pomaga. Każdy był w tej sytuacji na początku, także wie jak to było i wie, że czasem trafia się na ścianę, że ma się jakiś problem, z którym nie można sobie poradzić i fajnie jest pójść do kogoś kto Ci to.. kto Ci pokaże inną perspektywę. Być może naprowadzi Cię na coś. Niekoniecznie da od razu jakąś gotową odpowiedź, ale wskazówki, które pozwolą zrobić zadanie do końca i zrobić je dobrze.

Dima: Ona właśnie wspominała, że bardzo dobrze jak junior ma mentora, do którego zawsze może pójść i zapytać się o cokolwiek. Czy Ty masz taką osobę i czy pytasz konkretnie tę osobę, czy każdego developera w firmie?

Agnieszka: Mam mentora, a raczej mentorkę, która zawsze mi pomaga, kiedy natrafiam na jakikolwiek problem i zawsze znajdzie dla mnie chwilę. Co jest dla mnie bardzo ważne i jest dla mnie wielkim wsparciem, bo faktycznie mogę przyjść do niej z każdym problemem. Nie odeśle mnie z kwitkiem i zawsze mi wytłumaczy bardzo przystępnie lub podeśle jakieś materiały, z których mogę sobie coś poczytać. Także naprawdę uważam, że jest to bardzo ważne.

Oczywiście też jest tak, że moja mentorka ma swoje zadania i pracuje w osobnym teamie, także nie zawsze jest tak, że ma czas dla mnie i powiedzmy kiedy czuję, że ona właśnie ma nawał pracy i jest powiedzmy jakiś intensywny czas to też nie mam problemu z tym, żeby podejść do kogokolwiek innego. Wszyscy naokoło mi mówią, że jeżeli mam jakikolwiek problem to żeby do nich przychodzić i żeby pytać, bo jeżeli tylko dadzą radę to mi pomogą, a w większości wypadków jednak dadzą radę.

Dima: Ok. Właśnie, jeżeli chodzi o czas, też było wspominane w prezentacji, że dla juniora jest bardzo ważna jest rzecz taka rzecz jak time management. Warto nie spędzać za dużo czasu nad rozwiązaniem problemów, które są za trudne dla juniora i generalnie bardzo zarządzać swoim czasem i bardzo mądrze. To jest bardzo ważne.

Czy używasz jakichś narzędzi do zarządzania czasem oprócz tego co używamy wszyscy do zadań? Prezenterka mówiła o kalendarzu Google.

Agnieszka: Tak. No my używamy akurat w pracy Jira’y i mamy też planowanie sprintu, na którym wyznaczamy sobie na każdy dzień zadania, planujemy sobie daną ilość wyznaczonych godzin jakie mamy przepracować. Każde zadanie sobie estymujemy na planowaniu ile może zająć i później uzupełniamy każdy dzień danego tygodnia.

Powiedzmy, jeżeli sprint jest tygodniowy, to w ciągu tygodnia rozdzielamy sobie te zadania na cały tydzień tak, żeby wypełnić sobie cały ten dostępny czas. Jeżeli pracujemy powiedzmy - 8 godzin - to efektywnego programowania jest 5. W tym są oczywiście też zawarte zadania, jeżeli mamy o czymś poczytać i czegoś się nauczyć i zagłębić jakąś wiedzę. Także te 3 godziny, które pozostają to jest czas dla mnie na jakieś jedzenie, dodatkowe spotkania i wszelkiego rodzaju rzeczy, które dzieją się w firmie.

Uważam, że to bardzo pomaga, bo faktycznie na planowaniu jestem w stanie ocenić z moją mentorką ile mniej więcej może mi zająć to zadanie i mogę je jakoś wyestymować, ona może to skontrolować i powiedzieć mi powiedzmy, że: „No jednak tutaj nie wzięłaś wszystkiego pod uwagę także daj sobie troszkę więcej czasu”.

Powiedzmy, że jeżeli robię dane zadanie, włączam sobie timer i jeżeli dochodzę do takiego momentu, kiedy wykorzystuję cały ten założony czas, a zadanie dalej nie jest rozwiązane i mam problem - bo jeżeli wiem jak rozwiązać i wiem co zrobić dalej tylko po prostu mi się rozciągneło no to powiedzmy, że staram się raczej robić je dalej i nie zawracać nikomu głowy, ale jeżeli nie wiem to to jest dla mnie sygnał kiedy idę do mojej mentorki i pytam.

Pokazuję jaka jest sytuacja, ile miałam dostępnego czasu, ile zrobiłam i czy nie może mnie jakoś wspomóc i jakoś popatrzeć na to co zrobiłam i ewentualnie dać mi jakąś radę jak mogę sobie z tym poradzić dalej, jeżeli się zablokowałam bo zdarza się tak.

Dima: A taka wycena za zadań? Czy na początku zgadzały się wyceny i realne czasy wykonania zadania? Czy to po prostu na początku było to takie trochę strzelanie i później z czasem i z doświadczeniem to poprawiasz, czy od razu było tak, że zadania były wycenione mniej więcej na tyle ile zajmowały w rzeczywistości?

Agnieszka: Na początku myślę, że to jest zawsze strzelanie, przynajmniej w moim przypadku to było strzelanie. Nie miałam wielkiego pojęcia ile może mi zająć dane zadanie, szczególnie, jeżeli zajmowałam się rzeczami, z którymi wcześniej nie miałam styczności.

Powiedzmy, wydzielenie serwisu, którego wcześniej nie wydzielałam - nie do końca wiedziałam ile może mi zająć. Posiłkowałam się właśnie też na pewno moją mentorką, która mi troszkę podpowiadała, ale to też każdy chyba musi się nauczyć sam wyceniać zadania, także były często przestrzelone. Czasem robiłam krócej, czasem robiłam dłużej.

Jeżeli krócej to zawsze są jakieś dodatkowe zadania, które można sobie dobrać, jak dłużej no to wtedy właśnie kiedy kończy mi się czas no to idę i rozmawiam z moją mentorką. Także myślę, że ciężko jest się tego nauczyć. Uczymy się tego cały czas prawdopodobnie, ale pewnie wraz z doświadczeniem przychodzi to coraz łatwiej.

Dima: Też nawet był taki cytat na jednym ze slajdów, że „Every junior developer has the burnout”. Czy miałaś coś takiego w swojej historii i jak sobie z tym poradziłaś, jeżeli tak?

Agnieszka: Szczerze mówiąc to wydaje mi się, że jeszcze nie miałam.

Dima: Jeszcze?

Agnieszka: Być może mnie to jeszcze spotka, myślę że mogło być blisko, ale trafiłam do inFakt i tak naprawdę zostałam tu bardzo fajnie przyjęta i dostałam bardzo mocne wsparcie właśnie mentorskie, gdzie pozbyłam się wszelkich wątpliwości i jest to dla mnie bardzo duża wartość.

Dima: Prezenterka wspominała, że jednym ze sposobów na uniknięcie takiej sytuacji jest ustawienie sobie celów, takich jak short term goals i long term goals. Możesz opowiedzieć o swoich? Jakie masz cele na karierę, jakie masz długoterminowe cele?

Na przykład prezenterka mówiła, że chciałaby „dorosnąć” do project managera

Agnieszka: Szczerze mówiąc, to na ten moment najbardziej chciałabym rozwijać się, tak żeby dojść do poziomu seniora w Ruby. Dalej oczywiście, że gdzieś tam z tyłu głowy myślałam o takich stanowiskach jak Scrum Master czy Product Owner, ale chciałabym się skupić.. Znaczy właśnie to tak ciężko, bo to są długoterminowe cele, ale ten długoterminowy cel tak naprawdę żeby stać się seniorem to też nie jest moment. Także na ten moment chciałabym jak najbardziej się rozwinąć w samym języku i na pewno chciałabym się też nauczyć jakiegoś innego języka programowania.

Dima: No właśnie. Jaki sposób rozwoju i trochę eskalowania bardziej Ci odpowiada? Developer, który jest dobry w jednym języku i teraz kiedy jest czas na dalszy rozwój po prostu pociąga inne technologie? Czy developer, który jest dobry w jednym języku i dalej rozwija swoje umiejętności menadżerskie? Która ścieżka Ci bardziej odpowiada? Więcej technologii, czy przejście do innego trybu?

Agnieszka: Ciężko jest mi ocenić menadżerowanie, bo nie miałam do tej pory z tym wielkiej styczności. Na pewno chciałabym spróbować i pewnie jak spróbuje to ocenię, czy chciałabym iść w to dalej. Także ciężko jest mi na ten moment to właśnie powiedzieć, bo myślę, że to przyjdzie do mnie z czasem. I troszkę jeszcze te moje cele się jakoś tam w głowie rozwijają. Mam sporo pomysłów, ale nie są one jeszcze sprecyzowane - myślę, że spokojnie do pierwszego roku pracy, kiedy będę się jeszcze uczyła to się pewnie wyklarują już silnie. Silniej na pewno, niż w tym momencie. Ale na ten moment stawiam na to, żeby się jak najbardziej rozwijać i jak najwięcej się uczyć, także nie myślę aż tak długoterminowo o menadżerowaniu, ale na pewno chciałabym spróbować.

Dima: Ok. W prezentacji było bardzo dużo takich rad dla juniorów. Którą najbardziej weźmiesz pod uwagę w swojej dalszej pracy?

Agnieszka: Którą najbardziej wezmę pod uwagę? Szczerze mówiąc uważam, że to był zbiór takich zasad, które.. z których wszystkie były ważne. Zarówno to, żeby pytać o rady, to żeby dobrze zarządzać swoim czasem. Ciężko jest mi wycenić, która jest najważniejsza.

Trzeba znaleźć chyba swój „złoty środek”. Ja raczej staram się nie bać pytać i zarządzać sobie czasem. Właśnie to tak naprawdę jest narzucone przez system Scrumowy, także dalej się go uczę i staram się z nim współpracować. Nie wiem, która jest najważniejsza. Wszystko jest ważne. Na pewno też to, żeby pamiętać o sobie. I żeby faktycznie się właśnie nie wypalić to dawać z siebie dużo, ale robić sobie też jakieś przerwy, bo to jest potrzebne do regeneracji i do tego, żeby mieć siłę dalej się rozwijać, bo to jest ciągły rozwój.

Dima: I to może być taką radą dla juniorów od Ciebie?

Agnieszka: Myślę, że tak.

Dima: A powiedz jeszcze jedno. Rada dla managerów od siebie?

Agnieszka: Dla managerów?

Dima: Mhm. Też było o tym wspomniane na prezentacji. Kilka albo nawet kilkanaście rad dla managerów. Która według Ciebie jest ciekawa? Albo zupełnie Twoja?

Agnieszka: Tak naprawdę to wszystko było związane z tym, żeby „być” dla tego juniora i żeby go wspierać, żeby powiedzieć mu „stop”, jeżeli przesadza w jakimś momencie, że się przepracowuje, żeby pomagać mu w trudnych chwilach. I myślę, że to jest najważniejsze, bo jeżeli jesteś wrażliwy na tę drugą osobę i z nim rozmawiasz to wystarczy.

Dima: Dzięki.

Agnieszka: Dzięki.

Euruko 2017 - Summary of Day 1 (part 2)

Euruko 2017 - Sommary of Day 1 (part2)



Sebastian Bobrowski (CTO inFakt.pl):

Hej! Jesteśmy po pierwszym dniu konferencji. Jak wrażenie? Jakie takie główne punkty z dzisiejszego dnia wynieśliście?

Dima Boyko (Software Engineer, inFakt.pl):

Dosyć fajna była prezentacja założyciela Ruby twórcy Yukihiro Matsumoto. Bardzo mi się podobała. Wskazała kierunek rozwoju języka i dla developera wydaję mi się to jest ważne, że taka osoba pojawiła się na tej konferencji. Bardzo mi się podobała ta prezentacja. Chyba najwięcej zapamiętałem akurat z tej.

Sebastian Bobrowski (CTO inFakt.pl): Ok, jakieś jeszcze inne prezentacje?

Dima Boyko (Software Engineer, inFakt.pl): Była też prezentacja o Data Warehouse, o Shopify, o sposobach wyciągnięcia danych, które są potrzebne do różnych algorytmów właśnie dla wyciągnięcia takich danych na zewnątrz. Była też prezentacja o Distributed Systems..

Sebastian Bobrowski (CTO inFakt.pl): A wracając do tych hurtowni danych jakoś wiesz w inFakcie można by tego użyć? Albo wyjaśniło Ci to sposób w jaki coś można by inaczej zrobić? Lepiej?

Dima Boyko (Software Engineer, inFakt.pl): Wydaję mi się, że mieliśmy kilka razy, spotkaliśmy problemy, które dałoby się rozwiązać posiadając taki Data Warehouse, więc jak najbardziej widzę taką możliwość.

Sebastian Bobrowski (CTO inFakt.pl): Ok. Jakaś jeszcze prezentacja ci zapadła w pamięć?

Dima Boyko (Software Engineer, inFakt.pl): Też była fajna prezentacja o Distributed Systems od pracownika DigitalOcean. Pokazał w sumie wiele rzeczy, których już teraz używamy co jeszcze raz udowadnia, że robimy coś dobrze.

Sebastian Bobrowski (CTO inFakt.pl): Ok. Matz tam wspomina o tym, że język jest wolny. Czy według Ciebie on jest wolny?

Dima Boyko (Software Engineer, inFakt.pl): Nie. Próbowałem dzisiaj też dostać odpowiedź na takie pytania wiele razy i w sumie nikt mi nie udowodnił, że jest wolny bo nie jestem w stanie uwierzyć.. Jakby, jestem w stanie uwierzyć w takie sztuczne benchmarki widziałem to, ale w praktyce nie wiedziałem, żeby był wolny.

Sebastian Bobrowski (CTO inFakt.pl): Nie spotkałeś się nigdy, że gdzieś się zwolniło to w jakimś momencie?

Dima Boyko (Software Engineer, inFakt.pl): Bardziej, dużo bardziej zwalnia aplikację: zapytania do bazy, architektura i takie różne rzeczy, a niż tam język.

Sebastian Bobrowski (CTO inFakt.pl): Ok, ok. Radek, takie jakieś najważniejsze punkty z Twojej strony dzisiaj po pierwszym dniu konferencji? Zmęczony, nie zmęczony?

Radek Rochmalski (Full Stack Developer, inFakt.pl):

Jasne, że zmęczony. Z mojej strony.. Ja mam taki punkt widzenia: im dłużej tam uczestniczę, im dłużej wykorzystuję obiekt do swojej pracy, im dłużej uczestniczę gdzieś tam w środowisku Ruby, im częściej jeździmy na jakieś konferencje przekonuję się, że Ruby ma szansę, a nawet idzie w kierunku języka, który może zostać wykorzystany do budowy systemów klasy enterprise. To jest odważne słowo, natomiast przez powiedzmy 25 lat Ruby utrzymał się na rynku. Były różne technologie. Nie oceniam, która jest lepsza, która mniej lepsza. Natomiast wiadomo, że się utrzymał i to znaczy, że ma sens, prawda? Nie jest to może technologia, która jest kluczem do przyszłości, ale..

Sebastian Bobrowski (CTO inFakt.pl): Takiej dalekiej przyszłości?

Radek Rochmalski (Full Stack Developer, inFakt.pl): Tak, dalekiej przyszłości. Natomiast w moim przekonaniu ma duży sens zarówno sama technologia jak i jej używanie. Tutaj chociażby można by powiedzieć, że w kontekście rozwoju planowanego Ruby warto wspomnieć, że tam autor chce odpiąć tą łatkę słabego performance w Ruby i spowodować, żeby przyspieszył czterokrotnie w niedalekiej przyszłości.

Natomiast warto sobie zadać pytanie, czy to jest blokadą dzisiaj, ten performance, prawda? Często się mówi: „A, bo Ruby jest wolny.”. Natomiast czy my mieliśmy produkcyjne zdarzenie takie, gdzie faktycznie ten Ruby nie dał rady? Ja osobiście nie miałem, więc uważam że to nie jest jakiś tam minus jakby słaba strona. Natomiast warto sobie też przypomnieć w jakim celu powstał Ruby. Powstał przede wszystkim po to, aby wytwarzać oprogramowanie szybko i zwinnie i mi się to bardzo sprawdza.

Sebastian Bobrowski (CTO inFakt.pl): Ten cel jest dla Ciebie spełniony?

Radek Rochmalski (Full Stack Developer, inFakt.pl): Jak najbardziej. Jestem w stanie..

Dima Boyko (Software Engineer, inFakt.pl): I żeby to było przyjemne o czym też wspominał Matz.

Radek Rochmalski (Full Stack Developer, inFakt.pl): Tak. Jestem w stanie szybko wytwarzać oprogramowanie. Jest ono wysokiej jakości, a mi osobiście sprawia to przyjemność. Ta praca jest lekka. I myślę, że to jest ten cel, do którego się powinno stosować Ruby. No i ja jestem bardzo zadowolony. Nie mam zamiaru wychodzić.

Sebastian Bobrowski (CTO inFakt.pl): Ok, a czy Matz was przekonuje jako taki lider technologiczny? Czy można mu uwierzyć? Czy jakby ufacie mu, że: a) Ruby będzie rozwijalny, b) że to jest dzisiaj jak gdyby technologia, która ma sens?

Radek Rochmalski (Full Stack Developer, inFakt.pl): Ja podchodzę do tego tak, że.. Nie wiem jak to zabrzmi, natomiast nie ufam osobom, tak. Technologia, wartość danej technologii nie jest dla mnie powiązana z kimkolwiek, z żadną osobą. Ona nie stoi za technologią. Wiadomo ktoś tworzy daną technologię, natomiast ja nie interpretuję tego w sposób taki, że czyjeś tam opinie bądź wyrażenia powodują coś, raczej weryfikuję technologię. Weryfikuję co ona potrafi i albo się nadaję albo się nie nadaję.

Sebastian Bobrowski (CTO inFakt.pl): No bo mnie to na przykład przekonuje. Mnie jakby Matz przekonuję do tego, że robi to 25 lat..

Dima Boyko (Software Engineer, inFakt.pl): Dokładnie. Bardziej przekonuję właśnie to, że technologia już jakby żyję 25 lat i on to podtrzymuję ten taki..

Radek Rochmalski (Full Stack Developer, inFakt.pl): Tak. Tylko, że on opisuję to co się dzieje. To jest to o czym ja mówię. Możesz sobie to zweryfikować. No to istnieję, oczywiście to jest jakby zasługa, natomiast to jest opis. Dalej to jest opis czegoś co jest faktem.

Sebastian Bobrowski (CTO inFakt.pl): Tak, ale jakby ufam mu jako takiemu jakby liderowi tej technologii. Wydaje mi się, że bierze za nią odpowiedzialność. To jest taka jakby jedna rzecz. Nigdzie nie mówi, że nie doprowadza do jakiejś wojny. Mówi: „Tak. Są zarzuty, że Ruby jest wolny. Coś z tym robimy.” Są zarzuty, że nie ma jakichś tam features „Tak. Coś z tym robimy”. I to mnie bardzo przekonuje i uważam, że to jest taki jak, gdyby bardzo duży sens.

Dima Boyko (Software Engineer, inFakt.pl): Robi fajne prezentacje.

Sebastian Bobrowski (CTO inFakt.pl): Robi fajne prezentacje i jakby nie zaognia.. Jak gdyby są takie prowadzone święte wojny pomiędzy tam zwolennikami języka A B C i technologii D, a to mnie jakby przekonuję, że tutaj jest wszystko tak jak gdyby na poziomie, to po pierwsze. I, że też dobrze się o tym komunikuje. I jak gdyby bardzo ważnym elementem wydaję mi się jest to, że się jakby komunikuje z tą społecznością.

Jestem na drugim EuRuKo i na drugim jest Matz.. Ale na trzecim jestem, tak, na trzecim jestem bo pierwszy w 2010 i na każdym wydaję mi się, że był Matz i jakby komunikuje potem co będzie, co było i jakie są jakby problemy. Taka transparentność, którą pokazuję. Wydaje mi się, że ona jest bardzo doceniana przez społeczność tego tam core teamu, ale też taką społeczność użytkowników Ruby , twórców gem’ów i tym..

Radek Rochmalski (Full Stack Developer, inFakt.pl): W porządku..

Dima Boyko (Software Engineer, inFakt.pl): Jestem ciekawy też alternatywnej opinii, bo Matz wspominał o Ruby 3.0 i takiej najbliższej przyszłości języka i technologii. Natomiast jutro powinna być prezentacja o Ruby 4.0 and Beyond także jestem ciekawy alternatywnego punktu widzenia na temat przyszłości technologii.

Sebastian Bobrowski (CTO inFakt.pl): Ok. A Radziu jakieś jeszcze..

Radek Rochmalski (Full Stack Developer, inFakt.pl): Ja jedno pytanie musze zadać. Czy Ty.. Bo mam takie wrażenie, że potrzebujesz tej osoby, która jest identyfikacją danej technologii. Potrzebujesz takiego zapewnienia albo formy komunikacji. To o czym ja mówię, że można sprawdzić zweryfikować. Tutaj widzę trochę inny punkt. Czy to jest spowodowane tym, że patrzysz na to przez pryzmat bardziej jako CTO, czy developer?

Sebastian Bobrowski (CTO inFakt.pl): Patrzę na to przez pryzmat trochę takie CTO, że to jest technologia, w którą warto.. W której jak gdyby czuję, że będzie stabilnie, że jakby dzięki tej technologii i zespołowi jestem w stanie dostarczyć tą wartość dla naszych klientów i jestem w stanie sprawić, że to będzie działać. Jestem przekonany wtedy o silnych podstawach.

Możemy jakby coś na tej technologii zrobić jakby dobrego, pewnie coś zepsuć, mieć jakby plusy i minusy, dostarczać lepsze lub gorsze oprogramowanie, ale te podstawy języka mamy dobre. No bo gdyby była technologia, z którą mam problem, nawet nie wiem jak dobrym zespołem byśmy tworzyli daną aplikację, no to gdzieś będzie się to tam sypać. Mnie bardzo przekonuje.

Przekonuje mnie to, że jest core team, który to rozwija i jest organizacja. To jest dla mnie ciekawe, że to jest taka niesformalizowana organizacja, ale to mnie przekonuje, że to ma sens i jakby jestem w stanie się pod tym podpisać i jakby opowiadać o tym dalej i też jakby zapewnić klientów, że technologia, w której dzisiaj jesteśmy osadzeni ona jest stabilna tam, jak gdyby z samego dołu.

Radek Rochmalski (Full Stack Developer, inFakt.pl): Jasne. Ok.

Sebastian Bobrowski (CTO inFakt.pl): A jakieś jeszcze inne prezentacje Ci dzisiaj zapadły w pamięć, które uważasz że..?

Radek Rochmalski (Full Stack Developer, inFakt.pl): To znaczy mam tutaj jakąś subiektywną wizję każdej z prezentacji, natomiast wolę opisać całokształt. Po prostu były, mówiąc wprost były po prostu prezentacje, które nie wniosły nic do mojego doświadczenia, ponieważ te tematy przerabiałem wiele lat temu. Tak więc było dosyć zróżnicowane. Mogę powiedzieć o ogóle.

Sebastian Bobrowski (CTO inFakt.pl): Ok, no bo jesteś już bardziej doświadczonym developerem, tak samo jak Dima. A dla początkującego developera? Uważacie, że dla osoby początkującej, czy taka konferencja wnosi dużo, mało, średnio?

Radek Rochmalski (Full Stack Developer, inFakt.pl): Myślę, że jak najbardziej ma sens. Warto pojechać, warto zobaczyć. Myślę, że na pewno wyniesie się wartość dodatnią bez względu na poziom doświadczenia.

Sebastian Bobrowski (CTO inFakt.pl): Ok. Dima, co Ty myślisz?

Dima Boyko (Software Engineer, inFakt.pl): No dokładnie. Właśnie ten przykład, że była cała prezentacja o technologiach, które znamy i używamy, tam systemy kolejkowania to według mnie dla osób, które nie wiedzą jak tego się używa to jest dobry start dlatego, żeby poznać i spróbować przynajmniej tam później. Uważam, że też wartość dodatnia na pewno jest.

Sebastian Bobrowski (CTO inFakt.pl): Dobra. Dziękuję w takim razie.

Radek Rochmalski (Full Stack Developer, inFakt.pl): Dzięki.

Dima Boyko (Software Engineer, inFakt.pl): Dzięki.

Euruko 2017 Summary of day 1

Euruko 2017 Summary of day 1



Sebastian Bobrowski (CTO inFakt.pl):

Piotr Bryniarski (Software Developer inFakt.pl):

Sebastian Bobrowski (CTO inFakt.pl): Piotrek, to Twoje pierwsze EuRuKo. Dzisiaj jesteśmy po pierwszym dniu. Jak wrażenia?

Piotr Bryniarski (Software Developer inFakt.pl):

Ja powiem może przewrotnie, że EuRuKo wcale nie jest konferencją tylko dla programistów Ruby. Zdecydowanie więcej można się było dowiedzieć o architekturze, o tym jak podejść do programowania, na co zwracać uwagę. Też były tematy DevOps, tematy światopoglądowe nawet się pojawiały, ale samego kodu w Ruby dużo nie było pokazane.

Sebastian Bobrowski (CTO inFakt.pl): Ok. Na pierwszej prezentacji widziałeś twórcę języka Ruby. Pierwszy raz go widziałeś na żywo. Co sądzisz o nim?

Piotr Bryniarski (Software Developer inFakt.pl): No myślę, że takie spotkanie z twórcą języka daję dobre wyobrażenie jak to czego używamy powstaje i skąd to się bierze. Myślę, że też jest ciekawe, jednak Ruby jest bardzo specyficznym językiem. Ciekawe jak to się ma w porównaniu z twórcami innych języków i czym się różni tak naprawdę.

Sebastian Bobrowski (CTO inFakt.pl): Ok, ale Ciebie on przekonał nie przekonał?

Piotr Bryniarski (Software Developer inFakt.pl): Za językiem zawsze stoi community, które go rozwija, więc w tym sensie przekonał mnie. No myślę, dał mi jakieś takie wyobrażenie skąd to się bierze. No myślę, że nie jest takim typowym tam programistą nerdem, zamkniętym. Ma w sobie tak dużo, myślę elementów kultury japońskiej można powiedzieć, ale bardzo sprawia sympatyczne wrażenie.

Sebastian Bobrowski (CTO inFakt.pl): Ok, a pozostałe prezentacje? Jakaś ci szczególnie zapadła w pamięć?

Piotr Bryniarski (Software Developer inFakt.pl): O ostatnich prezentacjach myślę, że można powiedzieć zależały bardzo też od prezentującego. Ktoś mógł mieć ciekawy temat i go nie uciągnąć. Były tematy, które wcale nie sprawiały takiego super wrażenia, ale były ciekawie zaprezentowane.

Sebastian Bobrowski (CTO inFakt.pl): Jakaś jedna Ci zapadła w pamięć? Jakieś takie wiesz główne punkty?

Piotr Bryniarski (Software Developer inFakt.pl): Myślę warto wspomnieć, na końcu była prezentacja twórcy Bundler’a, w pięć minut przedstawił ciekawy temat nowej wersji Bundler’a, nowego podejścia do Gemfile i było to zrobione tak, że wciągało. Rozmowa o nazwie plików była naprawdę ciekawa.

Sebastian Bobrowski (CTO inFakt.pl): Forma Ci się podobała chyba..

Piotr Bryniarski (Software Developer inFakt.pl): Forma, ale też to, że krótko i treściwie wyjaśnił co, dlaczego i po co. Myślę, że ciekawa też była prezentacja o chwytliwym tytule dotycząca rzekomo skalowalnych systemów. W praktyce była prezentacja o zachowaniu w kryzysie aplikacji. No dała też wyobrażenie jak by był taki kryzys. Jakieś pomysły.

Sebastian Bobrowski (CTO inFakt.pl): F Jakiś jeden punkt co z niej zapamiętałeś? Piotr Bryniarski (Software Developer inFakt.pl): No myślę, że ważne było, żeby „na gorąco” nie programować tylko fixować. To ciekawe podejście. Zawsze mi się wydawało, że problemy rozwiązywać trzeba dobrze, twórczyni uważa, że rozwiązanie problemu „na gorąco” nie będzie dobre.

Sebastian Bobrowski (CTO inFakt.pl): Ok, a jak oceniasz po pierwszym dniu poziom? Czy to jest taki poziom bardziej dla początkujących, średniozaawansowanych, zaawansowanych? Jak to czujesz?

Piotr Bryniarski (Software Developer inFakt.pl): Myślę, że dobór tematów jest bardzo właściwy. Przeplatają się prezentacje na poziomie wysokim i skomplikowanym i takie luźniejsze tak, żeby cały czas nie zamęczać odbiorców i są na różnym poziomie, tak można powiedzieć. Zależy to pewnie jak ktoś był wgryziony w dany temat. Myślę, że każdy coś dla siebie może ciekawego znaleźć.

Sebastian Bobrowski (CTO inFakt.pl): Wybierasz się w następnym roku?

Piotr Bryniarski (Software Developer inFakt.pl): To możliwe. Myślę, że to ciekawe wydarzenie.

Sebastian Bobrowski (CTO inFakt.pl): Dzięki bardzo.

Piotr Bryniarski (Software Developer inFakt.pl): Dzięki.

Test-driven development (TDD) wnioski po szkoleniu

Podsumowanie szkolenia z Test-driven development



Dima Boyko (Software Engineer, inFakt.pl): Cześć! Nazywam się Dima i dzisiaj cały dzień spędzamy na szkoleniu z Test – driven development (TDD). Mam nadzieję, że poznam dużo więcej teorii na temat TDD i sposobów jak to zastosować w praktyce.

Cześć! Jesteśmy dzisiaj poza biurem cały dzień na takim szkoleniu z TDD. Powiedz proszę co to za szkolenie? Dlaczego tam jesteśmy? I skąd w ogóle pojawił się pomysł takiego szkolenia?

Sebastian Bobrowski (CTO inFakt.pl): Wiesz, w aplikacji takiej jak inFakt testy są jakby bardzo ważnym elementem bo pracujemy na danych księgowych klientów i to, żeby się liczył PIT, VAT poprawnie, żeby generowały się poprawnie deklaracje i rejestry jest super ważne, no i żeby to dobrze działało to z jednym z elementów są testy. Wszyscy te testy piszą, jakby każdy kto przychodzi jakieś tam ma podstawy samego pisania testów.

O TDD natomiast, każdy tak wiesz słyszał, ale często tylko słyszał, a wiesz, mało kto to stosuje w praktyce. I sam się chciałem też bardzo mocno tego nauczyć i stąd idea tego, że zróbmy takie szkolenie, taki wstęp do TDD, tak żeby zrozumieć z jednej strony filozofię i z drugiej strony coś spróbować się tak nauczyć realnie.

Dima: A powiedz proszę jak wygląda proces nauki TDD na takim szkoleniu? Opowiedz co robiliśmy i jakie to ma efekty.

Sebastian: No ten proces nauki TDD był bardzo powiązany z techniką, która mi się podoba, czyli pair programming. W takim kontekście, że w TDD są takie trzy, jakby każdy cykl składa się z trzech elementów: red – green – refaktor. W red najpierw piszemy test, który z definicji ma nie przechodzić, później sprawiam żeby był zielony, czyli piszemy kod produkcyjny który wykonuję, także ten test przechodzi, a na końcu jest refaktor. Tutaj Pair Programming bardzo mocno się sprawdza, ponieważ na te trzy cykle można się zamieniać klawiaturą.

Mieliśmy takie ćwiczenie w parach, gdzie dwie osoby pracowały przy jednym laptopie i na przykład: ty najpierw pisałeś test, który nie przechodzi, następnie ja robiłem implementację produkcyjną i klawiatura wracała do ciebie po to, żeby zrobić refaktor tego co ja wcześniej zrobiłem. No i to wydaję mi się, że jest całkiem niezła technika, jak tego się nauczyć nawet gdy później nie piszę się, nie stosuję się TDD w codziennej pracy łącznie z pair programming. To samemu można takie robić sobie w głowie trzy cykle, że jest red – green – refaktor. To wydaję mi się, że jest niezła technika do tego, żeby się nauczyć. Ja dużo zrozumiałem, więcej niż wiedziałem wcześniej.

Dima: Właśnie wiem, że bardzo często stosujemy pair programming i właśnie siedzimy przy jednej maszynie. Uważasz, że przy produkcyjnym pisaniu testów do aplikacji produkcyjnej warto stosować taki sam tryb jak robiliśmy na szkoleniu, że siedzimy we dwóch i piszemy te testy? Czy bardziej pair programming osobno, a takie TDD w takie tryby przełączać samemu dla siebie?

Sebastian: Wydaję mi się, że warto spróbować, nigdy wcześniej tego nie robiłem tak produkcyjnie. Ta klawiatura na pewno tak dynamicznie wtedy się rusza pomiędzy osobami, ale no w tym przykładzie, który robiliśmy było stosunkowo łatwe zadanie, więc ona jak gdyby dużo „biegała”. Pewnie w takim naszym jakimś produkcyjnym zadaniu, no to jakby ten czas na napisanie dobrych testów i nad nimi się zastanawianie jest większy. Później czas na napisanie kodu i na refaktoryzację jest większy, więc pewnie nie jest to tak dynamicznie. Wydaję mi się, że można to co najmniej przetestować.

Dima: Ok, a jak oceniasz to szkolenie pod względem takiej wiedzy? Czy dużo się nauczyłeś? Czy większość tego już wiedziałeś i teraz to była po prostu okazja, żeby to sobie przypomnieć albo poćwiczyć albo po prostu większość z technik TDD dowiedziałeś się tutaj?

Sebastian: Jakby wiedziałem, znałem takie podstawy teoretyczne, nigdy nie miałem tej wiedzy takiej ugruntowanej i nigdy tego nie miałem takiego jakby wiesz opowiedzianego w praktyce. No i tu mieliśmy Krzyśka, który nas szkolił, który 95% swojego czasu pracy, pracuje w ramach TDD, więc ma z tym na pewno duże doświadczenie, no i od niego jakby dużo zrozumiałem tego w jaki sposób można to tak w praktyce stosować. Także wiesz, coś wiemy teoretycznie, ale do praktyki czasem jest kawałek, no i mnie to bardzo mocno przybliżyło. Nie dowiedziałem się nic takiego super odkrywczego, ale te rzeczy, które były, były takimi bardzo dobrymi podstawami do tego, żeby zacząć to stosować na co dzień, by móc iść dalej w tym kontekście.

Dima: Czyli wyniosłeś trochę wiedzy z tego szkolenia?

Sebastian: Wyniosłem wiedzę. Wyniosłem takich wiesz wiele tipów jak to zrobić. Na przykład o tym, że można na kolejne te etapy przerzucić tę klawiaturę, na kolejne etapy od jednego developera do drugiego. Nie wiedziałem, że to tak można zrobić.

Dima: Ok, a pamiętasz na przykład czym się różni w testach, w aplikacjach Rails i ogólnie w testowaniu Fake, Stub i Mock na przykład?

Sebastian: Wiedziałem to wcześniej, ale nigdy tego tak dobrze nie umiałem opowiedzieć. I teraz już wiem, że Mock musi zostać wywołany i tutaj jakby badamy, czy dana metoda na przykład innej klasy została wywołana, natomiast Stub bardziej zwraca nam wartość. Jeżeli chcemy mieć jakąś wartość, to wtedy stub-ujemy, natomiast jeżeli chcemy zbadać czy inna metoda w innej klasie została wywołana, to wtedy to mock-ujemy.

Dima: Ok, a tak jeszcze podsumowując szkolenie, jakbyś nazwał trzy punkty, o których warto pamiętać przy napisaniu testów? Trzy punkty super ważne przy napisaniu testów? Jakie powinny być te testy?

Sebastian: Te testy na pewno powinny być takie wyizolowane, testy poprawiają nam architekturę. Bardzo mocno o tym nam Krzysiek jako szkoleniowiec opowiadał, że testy poprawiają nam architekturę, ponieważ najpierw jakby się zastanawiamy nad architekturą. To jest tak, że klasę w Ruby, czy w dowolnym języku to każdy jest w stanie napisać.

Natomiast dobra architektura wymaga już trochę więcej jakby myślenia i więcej zrozumienia, więc dobre testy są dla mnie takie, które powodują, że architektura jest dużo lepsza, też szybko działają. No bo to jest też bardzo ważny element, szczególnie w dużej aplikacji testy muszą się nam szybko uruchamiać i szybko się wykonywać, po to, żebyśmy informację o tym, że test przechodzi lub szczególnie nie przechodzi, mieli szybko. To myślę, że takie najważniejsze punkty.

Dima: To podsumowując, uważasz że było warto poświęcić dzień pracy developerów na takie szkolenie? Jakie są korzyści w ogóle z TDD w biznesie w praktyce?

Sebastian: Wydaję mi się, że warto. Dla mnie bardzo ważnym elementem jest to, żeby osoby które mamy dzisiaj w zespole były coraz lepszymi developerami i jednym z elementów tego jest TDD. Moja wizja jest też taka, że wiesz jako zespół techniczny, zespół IT, zespół developerów nie chcemy się tak bardzo mocno rozrastać.

Chcemy, żeby były nowe osoby, ale nie chciałbym żeby było to tak bardzo mocno, a żeby realizować potrzeby biznesowe możemy to zrobić w ten sposób, że właśnie się szkolimy, po to żeby praca każdej osoby była dużo bardziej efektywna, aby „jeździć z taczkami dużo bardziej zapakowanymi niż z pustymi”. Według mnie warto poświęcić jeden dzień, co najmniej jeden dzień i też kolejne dni żeby praca każdej osoby była dużo bardziej efektywna i przynosiła dużo więcej radości.

Dima: A tak konkretnie z tego szkolenia, jakie są korzyści takiego TDD i zastosowania TDD u nas?

Sebastian: No to na pewno lepsza architektura. To jest taki dla mnie główny element, po to żeby coś łatwo było przetestować musi to być łatwo implementowalne i wtedy, jeżeli się nad tym zastanawiamy w momencie przed implementacją, no to dużo łatwiej podzielić sobie to na moduły i klasy. Drugim ważnym elementem jest taka pewność tego, że wypuszczamy dzisiaj kod na produkcję i że on działa. Został przetestowany, wiadomo że został przetestowany częściowo ręcznie, najpierw zobaczył to pierwszy developer, drugi, potem tester, zwykle jeszcze Product Owner zobaczył czy ten kod faktycznie działa, ale no nie zawsze przetestujemy wszystkie elementy.

Natomiast TDD daję nam to, że jesteśmy w stanie mieć cały czas wszystkie przypadki przetestowane. Dzięki temu mamy później mniej błędów, mamy mnie debugowania, no i mniej czasu spędzamy nad tym, żeby się wracać, na tym utrzymaniu kodu, więc dla mnie to jest super technika i w inFakcie ona ma bardzo duże jakby znaczenie, ponieważ cały czas dobudowujemy do istniejącego produktu. W sytuacji, gdybyśmy mieli aplikację, którą robimy i za chwile ją przestajemy robić to pewnie mniej, natomiast my cały czas dobudowujemy do głównego produktu i dlatego bardzo ważne jest, żeby nie mieć tej takiej regresji wstecznej, czyli żeby nie mieć sytuacji, że z powodu tego, że mamy dzisiaj nową funkcjonalność jakaś tam inna, trzy funkcjonalności temu coś nam przestaję działać. No i tu TDD jest dla mnie jedynym możliwym rozwiązaniem.

Dima: Super, czyli idziemy teraz kontynuować tę szkolenie!

Sebastian: Tak jest.

Jak okiełznać Vima - historia dwóch developerów

vim-main

Każdy programista wie, że jednym z czynników, który pozwala zachować wysoką produktywność i efektywność, jest edytor kodu z jakiego korzysta na co dzień w swojej pracy. Część korzysta z IDE typu RubyMine, inni używają Sublime Text - a bohaterowie dzisiejszego artykułu - Kazimierz Szołtysik i Adam Winiarczyk - są miłośnikami Vima.

Vim jest narzędziem, które każdy może dostosować do własnego stylu, dlatego zdecydowaliśmy się na formę wywiadu, gdzie każdy z was będzie mógł poznać dwa różne punkty widzenia.

Vim to edytor tekstowy, napisany przez holenderskiego programistę Brama Moolenaara. Jest w pełni darmowy oraz dostępny na większość platform. Cechuje się wysoką konfigurowalnością, wsparciem dla wielu języków programowania oraz możliwością integracji z licznymi narzędziami. Powstał jako klon edytora vi. Sam też posiada odłamy - jednym z nich jest Neovim.

Dlaczego zainteresowałem się Vimem?

Adam:

Od zawsze słyszałem, że Vim potrafi być pomocny w pracy programisty. Tu i ówdzie pojawiał się w kursach, które przerabiałem.

W świecie Rails deweloperów jest całkiem popularnym edytorem, dlatego wielu programistów Rubiego stworzyło liczne wtyczki, które usprawniają jego pracę zarówno z kodem Ruby jak i innymi językami.

Dodatkowo, zawsze starałem się polepszyć zestaw narzędzi, z których korzystam, a Vim dość długo gościł na mojej to-do liście.

Przy pierwszym podejściu nie czułem, żeby moja szybkość oraz wygoda pisania kodu zwiększyły się - wręcz przeciwnie - sporo zwolniłem, co zniechęciło mnie do dalszej nauki.

Na szczęście miałem okazję do kolejnego podejścia, przy pair programmingu i code review z kolegą z pracy. Udało mu się zarazić mnie Vimem ponownie, tym razem już na dobre.

Dzisiaj nie wyobrażam sobie pracy przy użyciu innego edytora.

Kazik:

Gdy pierwszy raz zobaczyłem Vima przeraziłem się.

Co to jest? Jak zapisać plik? Jak z tego wyjść?

Po krótkiej przygodzie stwierdziłem, że to jakiś archaiczny twór niegodny uwagi. Są lepsze, nowocześniejsze edytory, np. Atom, Sublime...

Gdy po roku trafiłem na staż jako programista Ruby, zetknąłem się z Vimem ponownie. Wyszedłem wtedy ‘do ludzi’ i zauważyłem, że sporo pro developerów go używa oraz wygląda on u nich zupełnie inaczej niż ta najprostsza wersja, którą miałem okazję kiedyś odpalać. I że przypomina prawdziwe IDE.

Minęło jeszcze trochę czasu, zanim zacząłem się poruszać dość komfortowo w projektach Ruby on Rails. Zauważyłem wtedy, że moje IDE nie wyrabia przy dużych projektach. Wiesza się, długo startuje, zajmuje mnóstwo zasobów.

Pomyślałem, że może warto wrócić do tego Vima i dać mu szansę. Zbadałem temat ponownie i szybko okazało się, że przy użyciu pluginów mogę z Vima zrobić pełnowartościowe środowisko developerskie, które jest ultra lekkie, bardzo szybkie i całkiem wygodne.

W czym pomaga Vim?

Adam:

Vim:

  • Zdecydowanie pomaga w wykonywaniu naszych zadań bez opuszczania terminala. Często zadania, które wykonywaliśmy przy użyciu wiersza poleceń w terminalu, możemy przenieść do Vima, nie tracąc przy tym na swobodzie ich wykonywania.

  • Zwiększa naszą szybkość poruszania się po pliku, bez konieczności używania myszki, co pozwala nam na ciągłe trzymanie rąk przy klawiaturze.

  • Pozwala na nagrywanie makr, które ułatwią oraz przyspieszą wykonywanie powtarzalnych czynności np. usunięcie wybranych wartości z pliku csv, które spełniają nasze kryteria.

  • Po zainstalowaniu odpowiednich pluginów staje się IDE, w którym nie musimy klikać przez serię okienek, aby wykonać jakąś czynność.

Kazik:

Vim jest programem, w którym położono nacisk na operacje związane z łatwą, szybką i wydajną edycją plików.

Programista zdecydowaną większość czasu spędzonego nad kodowaniem poświęca nie pisaniu kodu, a raczej jego modyfikacjom, wyszukiwaniem czegoś w plikach, wraz z równoległym odpalaniem rozmaitych komend w konsoli (jest to zazwyczaj przełączanie się pomiędzy branchami w GIT, eksploracja historii commitów itp.).

Ponieważ Vim jest w stu procentach konsolowym programem, możliwe jest odpalanie z jego poziomu dowolnych komend systemowych, przekazując do nich dowolne parametry, również na podstawie tego, co np. aktualnie znajduje się pod naszym kursorem.

Zatem:

  • Nie ma więc problemu z odpalaniem testu w RSpec podczas pracy nad nim, bez potrzeby przełączania okien.

  • Można commitować zmiany w GIT ‘bezpośrednio’ z Vima. Vim oferuje też własny język skryptowy (Vimscript) i łatwe tworzenie własnych skrótów klawiaturowych, makr i komend.

Vim pomaga też bardzo w zaznajomieniu się z ‘unixowym sposobem myślenia’.

Dla przykładu:

  • wyszukiwanie łańcuchów znaków działa dokładnie tak samo jak np. w programie less. Ucząc się tej jednej rzeczy w Vimie, zyskujemy więc bonusowo umiejętność przeszukiwania wyników które zwracają nam wiele z unixowych poleceń, np. man, tail, git log itp.

  • jego znajomość przydaje się często w sytuacjach, gdy logujemy się zdalnie na serwer via SSH w celu wyedytowania jakichś plików (np. konfiguracji naszej aplikacji na serwerze testowym).

W czym przeszkadza?

Adam:

Mimo, że podczas sesji pair programmingu potrafi zrobić wrażenie na drugiej osobie, to jednak może być uciążliwy dla kogoś, kto nigdy wcześniej nie używał tego edytora. Praca z nim może stwarzać trudności nawet weteranom, gdy wykorzystamy konfigurację innej osoby dlatego, że w tej kwestii Vim pozwala na wiele (co jest również jego ogromną zaletą). Wspomniane problemy mogą skłonić nas do użycia innego edytora.

Kolejnym minusem może być przyzwyczajenie do sposobu pisania, jaki narzuca nam Vim. Pisząc w Wordzie czy Notatniku, chciałem używać skrótów, które mam zdefiniowane w Vimie i których używam na co dzień, a nie jest to możliwe i przełączanie się na początku sprawia problemy.

Mimo, że Vim istnieje od wielu lat, to cały czas się rozwija: powstają nowe wtyczki, dodawane są nowe funkcjonalności. Używam go od ponad roku, a nie czuje żebym znał jego wszystkie możliwości, cały czas odkrywam coś nowego. Wymaga odrobiny czasu w każdym miesiącu jeśli chcemy nieustannie polepszać swoje środowisko. Nie było chyba tygodnia kiedy bym nie zmienił czegoś w swoim pliku konfiguracyjnym. Niektórych może to po pewnym czasie zacząć męczyć.

Kazik:

Czasami ciężko jest wkleić tekst z systemowego schowka bezpośrednio do Vima i vice versa. Zajęło mi dużo czasu, zanim znalazłem na to dobry i prosty sposób: pbcopy i pbpaste. Są to dwa macowe narzędzia służące do kopiowania tekstu do i z systemowego schowka. Konfiguracja VIM z pbcopy to dodatkowa linijka w pliku ~/.vimrc:

vnoremap \<C-c\> :w !pbcopy\<CR\>\<CR\>

Najprawdopodobniej nie da się zrobić w Vimie wszystkiego tego, co np. w RubyMine - brakuje kilku pluginów, np. takich do zaawansowanego refactoringu.

Jednak największym minusem moim zdaniem jest dość wysoki próg wejścia w to środowisko. Zajęło mi kilka ładnych miesięcy, zanim poczułem się w Vimie na tyle pewnie, aby przestać korzystać z innych edytorów.

Jak przełamać barierę?

Adam:

Początki są ciężkie, zwłaszcza jeśli zdecydujemy się na tworzenie konfiguracji od zera. Czysty Vim, bez dodatkowych wtyczek i w podstawowej konfiguracji może odstraszyć, bo nie pozwala na wiele, co jest uciążliwe dla przesiadających się z innych edytorów lub IDE. Musimy zapamiętać wiele skrótów, nauczyć się je razem łączyć aby wydajniej pracować z Vimem.

Z ratunkiem przychodzi tutaj tworzenie cheatsheetów oraz https://vimawesome.com, kiedy potrzebujemy nowej wtyczki. Nie należy się zniechęcać za pierwszym razem, spadek komfortu pracy oraz wydajności jest czymś normalnym ponieważ Vim jest narzędziem, które musimy poznać, aby czerpać z niego korzyści. Nawet z pozoru proste rzeczy na początku mogą zająć dużo więcej czasu, niż przy użyciu zwykłego edytora.

Kazik:

Należy przede wszystkim zrobić tutorial (komenda w terminalu: vimtutor) i nie zrażać się ilością rzeczy do przyswojenia. Na początku MUSI być trudno, bo będziemy się uczyć czegoś w rodzaju nowego języka programowania.

Poruszanie się po tekście odbywa się w Vimie za pomocą tzw. motions i przynajmniej na początek - musimy poznać ich podstawy. Na szczęście wszystkie najważniejsze rzeczy są w tutorialu. Jeśli nie uda się nam ukończyć tego tutoriala w 30 minut, nie zrażajmy się - mało komu na początku udaje się to zrobić. Warto do niego wracać co jakiś czas, aby ugruntować podstawy.

Co dalej? Szukajmy sposobów na optymalizację naszych działań. Jeśli mamy wrażenie, że jakaś czynność zajmuje nam zbyt dużo ‘ruchów’ w Vimie, poszukajmy sposobu na zrobienie tego szybciej, w myśl zasady ‘1 nowa komenda co tydzień’. Notujmy je sobie i używajmy, aby utrwalić je w pamięci mięśniowej.

Gdzie szukać wsparcia?

Adam:

Aby uniknąć ciągłego wyszukiwania “jak zrobić X w Vimie”, warto przerobić chociaż jeden tutorial, co zaoszczędzi nam sporo czasu i pozwoli lepiej zrozumieć zasady działania edytora. Vim posiada wbudowany darmowy tutorial, który nauczy nas obsługi programu.

Dla początkujących, polecam poradnik w formie gry: https://vim-adventures.com.

Dla bardziej zaawansowanych, przydatne będą krótkie filmy instruktażowe: http://vimcasts.org/episodes. Autor Vimcasts napisał również 2 książki (Practical Vim oraz Modern Vim), które pozwolą nam na lepsze poznanie wybranych wtyczek.

Wiele można się nauczyć z plików konfiguracyjnych znalezionych na githubie, jednak ten sposób polecam również bardziej zaawansowanym.

Ostatnim wartym polecenia tutorialem jest https://github.com/mhinz/Vim-galore, w którym znajdziemy w pełni opisane zasady działania edytora oraz przydatne porady.

Kazik:

Vim jest oprogramowaniem open source ze sporą rzeszą użytkowników, co powoduje, że na praktycznie każde nurtujące nas pytanie znajdziemy w sieci odpowiedź.

Warto korzystać z pluginów, a najlepiej na początek używać specjalnej dystrybucji Vima (np. Vim janus), która posiada już zainstalowane sporo przydatnych pluginów, gotowe skróty klawiaturowe i ma wszystko dobrze udokumentowane w readme.

__

Wiecie już, jakie są za i przeciw korzystania z Vima oraz jak rozpocząć przygodę. W kolejnym artykule opiszemy możliwości wtyczek, które szczególnie przypadły nam do gustu.

Zachęcamy do postawienia pierwszych kroków i pamiętajcie, że Vim jest tylko pomocnym narzędziem i nie zrobi za nas wszystkiego.

__

http://www.vim.org

https://vim-adventures.com

http://vimcasts.org/episodes

https://github.com/mhinz/Vim-galore

https://vimawesome.com

https://github.com/carlhuda/janus

https://github.com/neovim/neovim

#Euruko2017 - Things I learned the Hard Way Building a Search Engine

Rozmowa i opinie po prezentacji “Things I learned the Hard Way Building a Search Engine”



Dima Boyko (Software Engineer, inFakt.pl): Hello. Byłem na jedzeniu, na lunchu i niestety nie zdążyłem na ostatnią prezentację. Powiedz, co tam było ciekawego. O czym w ogóle była ta prezentacja?

Alicja Cyganiewicz (Ruby developer, inFakt.pl): Wiesz co? To była prezentacja o wyszukiwaniu i wyszukiwaniu jak chodzi o teksty. Tzn. w jaki sposób możemy zwrócić użytkownikowi tekst, który najlepiej będzie odpowiadał temu, czego szuka. I najśmieszniejsze jest to, że właściwie robimy to codziennie, bo każdy z nas czegoś wyszukuje w Google i nigdy chyba się nie zastanawia nad tym jakim cudem faktycznie dostajemy to czego chcemy. A z wyszukiwaniem tekstu jest naprawdę ciężka sprawa, bo masz semantykę, której nie da się zmierzyć liczbowo. Jeżeli np. w zwykłej aplikacji wyszukujesz, nie wiem, fakturę, to jesteś w stanie podać jakieś konkretne jej dane, natomiast przy przeszukiwaniu tekstu wchodzą słowa, wchodzą jakieś takie znaczeniowe rzeczy i ciężko jest to zmierzyć w taki sposób, żebyśmy byli w stanie podać jakąś taką liczbową wartość. I okazało się, o czym ja np. wcześniej nie wiedziałam, nie zdawałam sobie sprawy, że jesteśmy w stanie w jakiś sposób przedstawiać liczbowo podobieństwo pomiędzy tym czego ktoś wyszukuje a tym co mamy w tekście. Okazało się… wiesz, gdyby się tak nad tym samemu zastanowić, to myślę, że też byłbyś w stanie wskazać taki jeden przykładowy licznik, co może być ważne. I np. ja wpisuję 3 słowa do wyszukiwania, mam masę tekstów, to zastanów się, co mógłbyś liczyć.

Dima: Ilość wystąpień tych słów w tekstach.

Alicja: OK. Czyli chodzi ci o to, jak często występowały w tekstach, tak?

Dima: To jest najprostsze.

Alicja: Widzisz i to jest trochę złudne. Dlatego, bo okazuje się, że tak naprawdę, jeżeli masz tekst, to każde następne wystąpienie tego samego słowa w tekście jest coraz mniej znaczące. Tzn., jakby największą wartość ma pierwsze wystąpienie danego słowa, bo to oznacza, że jakby ten tekst, faktycznie mówi na ten temat, ale każde kolejne wystąpienie ma coraz mniejsze znaczenie, bo możemy się też spodziewać, że skoro tekst jest na jakiś dany temat, powiedzmy szukasz tekstu o programowaniu w Ruby, to słowo kluczowe: Ruby, będzie się powtarzało w tym tekście, no i każde jakby kolejne wystąpienie będzie mniej znaczące. Ale faktycznie masz rację, że jakby częstotliwość jest tam jakimś jednym z mierników. Ale to co jest w gruncie rzeczy najważniejsze, to czy w ogóle dane słowo występuje i na prezentacji był np. pokazany sposób przełożenia występowania słów w tekście na wektory. To się wydaje zupełnie abstrakcyjne, bo z jednej strony masz tekst, czyli coś zupełnie takiego jakby odciętego od nauk ścisłych, a z drugiej strony masz przedstawienie tego wektorowe. Dzięki temu możemy np. wyliczyć taką pierwszą podstawową tzw. relevance, czyli to czy tekst odpowiada temu czego ktoś wyszukuje. I to jest ten taki podstawowy miernik. Później tak jak mówisz wchodzi częstotliwość występowania…

Dima: Ale pewnie jest zależna też od długości tekstu.

Alicja: Dokładnie tak.

Dima: Bo im dłuższy mamy tekst tym statystycznie prawdopodobieństwo wystąpienia tego słowa jest większe.

Alicja: Dokładnie tak. I dlatego jest też algorytm, który jakby coraz bardziej uszczegóławia to podobieństwo wyszukiwanej frazy do tekstów i tam właśnie tak jak mówisz, teksty, które są dłuższe, będą w cudzysłowie karane, czyli ilość wystąpień tych słów, będzie coraz mniej brana pod uwagę, no bo wiadomo, tak jak powiedziałeś, dłuższy tekst, większe prawdopodobieństwo. Natomiast te krótkie teksty… jeżeli w krótkim tekście wystąpi ci to chociaż raz, to i tak jest to dosyć ważne wystąpienie. Prawda? Można w ten sposób powiedzieć. Tylko że, tak jak powiedziałam, z tekstami najgorsze jest to… to jest semantyka, to jest coś nad czym do końca nie panujemy, dlatego trzeba też walczyć z synonimami. Warto zastanowić się właśnie nad tym jakie podobne słowa mogły tam wystąpić, jakie słowa z rodziny mogły tam wystąpić i tutaj wchodzi dosyć dużo takiej powiedzmy manualnej pracy. W sensie nie wszystko jesteśmy w stanie mierzyć algorytmami, bo ktoś musi wprowadzić, nie wiem, tzw. derywaty, czyli powiedzmy końcówki słów, w jaki sposób tam dane słowo może się odmieniać, żebyśmy później byli w stanie znaleźć to w tekście. I to jest coś moim zdaniem najtrudniejszego. To nie było powiedziane może na prezentacji, ale tak mi się wydaje, że to jest chyba najtrudniejsza część, jak chodzi o wyszukiwanie i przeszukiwanie tekstów, że w dużej mierze opiera się na danych, które my musimy wprowadzić, szczególnie, że każdy język będzie rządzi się swoimi prawami. Prawda? Np. język angielski nie będzie miał takiej odmiany przez przypadki jak ma język polski, więc w tym momencie jakby ta baza się troszeczkę zawęża.

Dima: A czy zdarzyło się w twojej praktyce implementować, albo używać jakiś gotowych rozwiązań do wyszukiwania tekstu? Czy znasz jakieś gotowe rozwiązania i czy mogłabyś coś polecić?

Alicja: Znaczy wydaje mi się, że takim najbardziej znanym rozwiązaniem jest Elasticsearch. On też był wspomniany na prezentacji. Natomiast przyznaję, że ja akurat z tego nigdy nie korzystałam, więc ciężko jest mi powiedzieć. Ale z tego co słyszałam to jest to, jak mówię, jedno z najlepszych narzędzi, jakie można używać w tym kontekście.

Dima: OK. Czyli generalnie message prezentacji jest taki, że nie musisz używać natural language processing dlatego żeby wyszukiwać tekst, tylko można przełożyć to na standardową matematykę.

Alicja: W pewnym zakresie tak, tylko, że dochodzi do tego masa kolejnych powiedzmy faktorów takich, które na to wpływają. One nawet nie były wszystkie wymienione, bo nie da się tak na prawdę wszystkich wymienić. Chociażby to, jak dostajesz frazę do wyszukiwania, to teraz możemy się zastanawiać, czy wystąpiła dokładnie w tej samej kolejności, czy wystąpiło dokładnie to złożenie tych słów koło siebie. Czasami to nawet jest gorsze, dlatego bo jeżeli wpisujesz tylko 3 słowa klucze, a nie wpisujesz zdania jakby takiego ludzkiego, no to jeżeli to wystąpi koło siebie, to ten tekst znaczy jakby ma niewielką wartość, więc jakby pojawiają się kolejne takie elementy, o których trzeba by było pamiętać pisząc takie wzory pozwalające na przeliczenie podobieństwa tekstu do wyszukiwanej frazy.

Dima: Czyli takie algorytmy muszą być bardzo trudne do zaimplementowania.

Alicja: Moim zdaniem tak i z prezentacji też to wynikało.

Dima: A jak uważasz, takie podejście wektoryzacji matematycznie pasuje tylko dla wyszukiwania tekstów, czy innych typów informacji też, pikseli np.

Alicja: Podejrzewam, że tym bardziej dla innych typów informacji. Że jeżeli coś jesteśmy… moim zdaniem tekst i w ogóle ludzka mowa, jako coś naturalnego jest tak trudne do ujęcia w ścisłe ramy, że jeżeli jesteśmy w stanie to przełożyć na matematykę, to tym bardziej jesteśmy w stanie wyszukiwać, tak jak mówisz, piksele.

Dima: A odnośnie jeszcze wyszukiwania tekstów. Kiedyś zauważyłem, że różne systemy, różne wyszukiwarki np. Google i DuckDuckGo, bardzo różnie interpretują zapytanie, które wprowadzam w pole tekstowe. Google np. rozumie to bardziej… bardziej sprawdza sens tego co ja piszę, natomiast DuckDuckGo wydaje wyniki, które po prostu bardziej psują językowo. Które z tych podejść wg ciebie jest bardziej…

Alicja: Wiesz co? Moim zdaniem lepsze jest wychwytywanie sensu szczerze mówiąc. Dlatego zwłaszcza że nie wszyscy użytkownicy potrafią dobrze formułować zapytania. Takie jest też moje zdanie, że jakby jedną myśl jesteś w stanie przedstawić na różne sposoby i w tym momencie jeżeli algorytm, który wyszukuje podobieństwo w tekście jest w stanie zrozumieć o co ci chodziło, to jest to dużo, moim zdaniem, bardziej wartościowe, niż tak jak mówisz względy językowe takie, strukturalne.

Dima: Czyli może zdarzyć się tak, że użytkownik wpisał jakieś zapytania i dostał w pierwszym rankingu odpowiedź, która nie zawiera w ogóle tego tekstu…

Alicja: Może się tak zdarzyć, jasne.

Dima: …bo algorytm stwierdził, że ma to większy sens.

Alicja: Podejrzewam, że tak, chociaż chyba nie zdarzyła mi się nigdy taka sytuacja, więc jest to taka trochę teoretyczna sytuacja.

Dima: OK. I na koniec jaki jeden najważniejszy punkt z tej prezentacji byś wspomniała.

Alicja: Przede wszystkim to, że jesteśmy w ogóle w stanie mierzyć to relevance czyli tą taką odpowiedniość wyszukiwanego tekstu do frazy. Moim zdaniem to jest taka główna myśl i że przede wszystkim, że to nie jest jakby konkretna wartość, ale, to co cały czas było podkreślane na prezentacji, że to jest… jakby to relevance zawsze będzie spektrum wartości.

Dima: OK. No to teraz mogę powiedzieć, że byłem na tej prezentacji.

Alicja: Cieszę się, że pomogłam.

#Euruko2017 - Data Driven Production Apps

Rozmowa i opinie po prezentacji “Data Driven Production Apps”



Dima Boyko (Software Engineer, inFakt.pl): Sebastian, opowiedz o czym była ostatnia prezentacja. Jak ci się podobała?

Sebastian Bobrowski (CTO inFakt.pl): Bardzo mi się podobała. Był człowiek z Shopify’a. Dla mnie Shopify to jest taka pierwsza poważna aplikacja Railsowa. Jak ja się zacząłem interesować Rubim i Railsami to Shopify już działał tak produkcyjnie na dużą skalę. To jest tam firma z Kanady dostarczająca oprogramowanie dla sklepów internetowych. To był dla mnie taki, przy podejmowaniu decyzji technologicznej, pierwszy duży punkt, że da radę na Ruby od Rails i Rubim zbudować działającą produkcyjną aplikację. Na tej prezentacji zrozumiałem taką historię trochę Shopify’a, jak to się zaczęło. No zaczęło się od tego, że budowali po prostu aplikację dla sklepów internetowych i ona działała dobrze, ale w pewnym momencie wyszedł temat danych i dlaczego warto je zbierać. Na początku wiedzieli, że są biblioteki machine learningowe, że sztuczną inteligencją można je analizować, natomiast na podstawie danych, które mieli, było dosyć trudno było to robić. Na początku próbowali to robić jakby wewnątrz aplikacji, dobudowywać modele, ale okazało się, że to jest bardzo trudne, jeżeli mamy aplikację, która robi jedną rzecz, czyli dostarcza coś dla sklepów internetowych, to bardzo trudno jest tam dobudować jakiś moduł, który coś tam analizuje. No i ważnym wtedy elementem było to, że zrozumieli, że potrzebują taki magazyn danych, taki data warehouse, po to, żeby tam trzymać te informacje. To jest dla mnie taka pierwsza, najważniejsza rzecz z tej prezentacji.

Dima: Myślisz, że chciałbyś wprowadzić w swoim produkcie, taki data warehause? Czy ma to sens dla takiej skali?

Sebastian: Wydaje mi się… Na pierwszy rzut oka, to jest takie powtarzanie danych, jak gdyby że trzymamy nagle te same dane w dwóch miejscach i na pierwszy rzut oka wydaje się to niezbyt dobrym pomysłem, ale jak się nad tym dobrze zastanowić, co można przy okazji zrobić i jakby jak ta logika mocno jest oddzielona, to wydaje mi się, że ma to duży sens. Wyciągnięcie tych informacji poza, oczyszczenie ich, on opowiadał o tym, że na pewno warto w tym momencie, gdy wyciągamy je z produkcyjnej bazy do tego magazynu, na pewno warto je wtedy oczyścić, tak, żeby mieć je mocno przygotowane i je wręcz włożyć do płaskiej tabeli, czyli żebyśmy nie mieli zależności, które są pomiędzy różnymi tabelami. Mamy kilkadziesiąt tabeli np. w Postgresie i po to, żeby wyciągnąć jedną informację, musimy zjoinować kilkadziesiąt tabeli, to wtedy przy tym takim preprocesingu danych w momencie ich wyciągania możemy je od razu umieścić w jednej tabeli i wtedy dla takiej osoby, która później pracuje z tym magazynem danych, dużo łatwiej jest to zrozumieć i wyciągać. Także jak najbardziej, ale na pewno nie jest to takie super proste zadanie.

Adrian Zięba (Software Engineer, inFakt.pl): Zwróć też uwagę, że on opowiadał o tym, że mieli problemy z główną aplikacją i nie mogli zapewnić użytkownikom podstawowych funkcjonalności, jeśli to wszystko się działo, to analizowanie danych, w tej głównej aplikacji, bo obciążyło to serwer głównej aplikacji i jednym słowem zabrakło mocy obliczeniowej dla podstawowych funkcjonalności. Więc pod tym względem też jest to dobrze dzielić, żeby dywersyfikować obciążenie głównych serwerów.

Sebastian: Jakby się nad tym zastanowić, to można spróbować zrobić tak, że wiesz, ż wydzielasz jakąś tam aplikację bazy danych pod to, żeby z niej tylko czytać te dane, natomiast pytanie, czy to wtedy już nie robisz tego magazynu tak powoli.

Adrian: No właśnie.

Dima: Osobna instancja aplikacji z bazą to jest taki trochę data warehause. Adriano wspominał, że bardzo lubi MongoDB. Uważasz, że na taki data warehouse nadaje się bardziej tradycyjna baza danych czy coś w stylu MongoDB?

Sebastian: Wydaje mi się, że tutaj taka NoSQL’owa baza ma duży sens, właśnie z tego powodu, że wyciągamy dużą ilość danych z takiej produkcyjnej aplikacji, możemy je wcześniej oczyścić, możemy je wcześniej przygotować i możemy je właśnie użytkując zapakować w takie gotowe rekordy, dzięki czemu mamy już je gotowe, możemy coś na nich działać, a nie musimy zawsze trzymać tego schematu. Jeżeli mamy jakieś obiekty, które mają dzisiaj składają się z pięciu wartości, a jutro dochodzi szósta, no to nie musimy jakby całości przebudowywać, plus dostęp do jednego obiektu jest bardzo szybki.

Dima: Ten spiker z Shopify też wspominał, że dzielenie takich danych pozwala użyć zupełnie innych technologii do obróbki tych danych. Uważasz, że warto na tym data warehause używać takiej samej technologii czy można pójść w zupełnie innym kierunku i w innej technologii inne paradygmaty stosować?

Sebastian: Wydaje mi się, że można tutaj… jakby jest bardzo wtedy łatwo użyć innej technologii, ponieważ dużo technologii szczególnie maszyn learningowych ma duże wsparcie dla tego, że mamy dane bezpośrednio w JSON-ie, a dużo mniejsze wsparcie np. dane, które są w SQL-u. Też się da, ale jeżeli mamy dane w JSON-ie, to mamy od razu wsparcie, możemy je bezpośrednio załadować np. do Scikit-Learn’a Pytonowego i „z pudełka” mamy od razu te dane dostępne, możemy je analizować, wyciągać z nich jakieś informacje, budować na nich widoki itd.

Adrian: Zwróć też uwagę, że oni też dokonali na końcu czegoś takiego jak komunikacji zwrotnej. Dlatego że z tego magazynu danych potrzebowali danych na temat, aktualnych danych i danych przewidywanych dla użytkowników odnośnie sprzedaży i później z powrotem, te dane wrzucili do aplikacji łącząc, komunikując je przez API. Więc to też jest tak, że niby te dane są osobno, ale masz też do nich dostęp, do tych rezultatów.

Sebastian: No, bo dzięki temu, że one są w stanie jakby wrócić. Bo tak naprawdę robimy to dla tego użytkownika końcowego. No i ten użytkownik końcowy później ma z tego wartość, bo jesteśmy w stanie te dane wstrzyknąć.

#Euruko2017 - Zapowiedź serii

Zapowiedź serii wideo z Euruko 2017 w Budapeszcie