Dziś dowiesz się jak wyglądają projekty Big Data. Czym jest PoC a czym produkcyjny. Jakie są środowiska. Jak organizować sobie pracę w Big Data. Co ważniejsze – dam instrukcję tego jak solidnie wejść w nowy projekt, żeby nie być lamusem przez kolejne pół roku;-).

Proszę, oceń ten odcinek i podaj go dalej;-).

Ja nazywam się Marek Czuma. Jestem inżynierem oraz instruktorem Big Data. Jestem również założycielem Riotech Data Factory i Akademii Big Data.

Kurs „Fundament Apache Solr”: https://kursy.riotechdatafactory.com/fundament-apache-solr/ oraz https://akademia-bigdata.pl/fundament-apache-solr/

• Spotify
• YouTube

Onboarding w projekcie Big Data. Instrukcja

1. Ogólny cel + architektura.
2. Poszczególne moduły + repozytoria do nich. Kluczowe mechanizmy modułów.
3. Moduły a infrastruktura.
   • Gdzie są dane?
   • Jak uruchamiane są joby?
   • Gdzie są logi i jak je przejrzeć?
   • (jeśli jest Spark) Gdzie jest History Server?
4. Linki do kluczowych miejsc. Repozytoria, serwisy, boardy (jira).
5. Jak wygląda proces deploymentu?

Transkrypcja odcinka

[Transkrypcja automatyczna, mogą pojawić się błędy]

Cześć, witam cię bardzo serdecznie w odcinku numer 20 Big Data po polsku. A dzisiaj zanurzymy się w branży, o, wprowadzę Cię tylnymi drzwiami do naszej branży i opowiem ci o tym, jak wyglądają projekty. Prawdziwy komercyjne projekty z wykorzystaniu Big Data, oczami moimi, czyli inżyniera Big Data. Pytacie mnie o to, co jakiś czas szczególnie w ramach mentoringu dostaje takie pytania, więc postanowiłem wyciągnąć ten temat troszeczkę poza sam obszar mentoringu i publicznie o tym opowiedzieć, jak to wygląda z mojej perspektywy. I opowiem ci od bardzo wielu różnych stron, tak żeby to przygotowanie było i odsąd organizacyjnej i technicznej i kulturowej można powiedzieć, ale przede wszystkim sądzę, że to, co najbardziej przyda instrukcję, jak u środku zawrę, instrukcja tego, czego możesz się spodziewać wchodząc świeżo w projekt, albo po prostu wchodząc do nowego projektu, niekojęcznie jako unior. Kilka bardzo konkretnych punktów, jeżeli jest spełnisz, to pierwszy tydzień czy dwa tygodnie będą mocno wykorzystane. No to co, jak to mój synek mówi, staltujemy. Kallujamy! Cześć, witam cię w podkaście Big Data po polsku. Poznajemy tu wspólnie jak działa świat, który jak wiadomo zbudowany jest z danych i rządzony jest przez algorytum. Jesteś w dobrym miejscu, jeśli interesują cię technologię, biznes, społeczeństwo, lub pogłębianie swojego potencjału i to wszystko w kontekście danych. Ja nazywam się Marek Czuma, jestem założycielem Rajo Tech Beta Factor, firmy, która pomoże ci zrozumieć Big Data, wymiaże technicznym i biznesowym. Nalej do kupka solidną porcję swojej ulubionej kawy, pakuj swoje rzeczy i rusza ich ze mną w tą fascynująco przygodę. Ok, ok, dzisiaj już wiesz o czym będziemy rozmawiać, powiem ci, jeżeli jesteś aspirującym, inżynierem Big Data, jak mniej więcej będzie wyglądać twoja robota, kiedy udać się już dostać do branży. Ale najpierw krótkie ogłoszenie, bo wiesz co, zorientowałem się, że 70% z tych, którzy oglądają Niena YouTube, nie zasubskrybowało kanału. Hej, ludzie, co z wami nie tak? Oglądasz podobać się to kliknij subskrypcję i dzwoneczek będziesz dostawać więcej. Będziesz dostawać zarówno kwestię takie, żejsze jak ta kwestie bezpośrednio z branży, jak i bardzo mięsiste. To dzień nic nie kosztuje. Klikaj dzwoneczek, klikuj subskrypcję i tyle. A jeżeli słuchasz tego na Spotify, oceń, bardzo serdecznie proszę, oceń, jeżeli słuchasz tego na komuulce wejdź sobie w stronę główną Spotify’a, na czy w główny widok i kliknij, tyle gwiazdy kileć się podoba. To też będzie bardzo miły pleasant dla mnie, dlatego że zauważyłem, że troszeczkę całkiem mocno nie to ciągamy z liczbą ocen względem tego ilo osób słucha. Dlatego bardzo proszę nadróbmy to, a teraz możemy jechać z koksem. No dobrze, no to jak wyglądają projekty u nas Big Data? Przede wszystkim zacząłem się podstawować rzeczy, które chciałem się podzielić na samym początku i ona zbuduje nam pewien obraz. My jako Big Data, prawie nigdy nie będziemy stąma procentami projektu. My raczej jesteśmy zawsze pewną częścią. Projekty nie służą i być może o tym zapomniałeś, a na pewno część osób o tym zapomina, że projekty nie służą temu, żeby programista miał pracę. Projekty, że nie służą, większości przypadków, to, żebyśmy my mogli się rozwijać albo my mieli jakieś przestrzeń, w której jest nam miło. Projekty służą konkretnemu celowi najczęściej biznesowemu, choć nie tylko. Oglnie życzą i mówiąc możemy powiedzieć, że biznesowem generalizujące. Co powoduje, że my zastanawiając się nad tym w którą stronę ma ich projekt co powinien zrobić, myślimy, jakie części poskładać. I tak może tam być np. aplikacja, może być związane z analizytyką, część związana z data science, a może być część związana też właśnie tak jak w naszym przypadku nas to interesuje z Big Data. Czyli my, prawie nigdy nie jesteśmy pełnią projektu Big Data, sama w sobie nie jest inaczej nie powinna być celem. Big Data zawsze będzie miała jakąś rolę służepną wobec większego celu. I to jest bardzo fajne. Rukami musimy sobie tu uświadomić. Musimy sobie to uświadomić dlatego, że to determinuje troszeczkę rzeczy w projekcie o czym będzie za chwilkę. Jego już sobie to uświadomimy, to możemy jechać z koksem i zastanawiać się jak wygląda prawdziwy produkcyjny, komercyjny projekt. Czy ja powiedziałem produkcyjny? No właśnie, tutaj warto rozgraniczyć parę rzeczy. Będziemy mówić o projektach komercyjnych, czyli takich za które ktoś wykłada pieniądze w związku z czym one powinny funkcjonować w ramach jakichś określonych zasad organizacyjnych. I to są projekty, w których uczekuje się od nas, że będziemy profesjonalnie i że będziemy konkretne efekty, jak to się mówi żargonem naszym w IT-dowozić. Będziemy dowodzić konkretne efekty, konkretne elementy projektu produkty. I to jest projekt komercyjny. Taką służy, komercji służy, najczęściej to może by zarabiać albo żeby przygotować coś co pozwoli zrobić w przyszłości. Natomiast w ramach takich komercyjnych produktów można rozgraniczyć 2 bardzo konkretne rodzaje. I pierwszy to jest, można powiedzieć chronologicznie, pierwszy to jest tak zwane POC, tuż po polsku podz, tuż jeszcze bardziej po polsku prototyp. A drugi rodzaj to są projekty produkcyjne. Czym on się różnią? POC czy też prototypy projektów? To są takie dużo mniejsze projekty. One służą nie temu, żeby coś jeszcze sprzedać, choć czasami też się robić, żeby POC zostaje później produktem końcowym. Natomiast co do zasady to ma być taki szybki skok, żeby zobaczyć czy jakaś koncepcja może być w ogóle zrealizowana, a jeżeli tak to w jaki sposób. I firma, na przykład jakichś bank może chcieć zbudować systema naityczny dla swoich transakcji powiedzmy karto. I ma konkretne cele, wiemy więcej jak to powinno wyglądać i teraz rozpisuje taki POC. I firmy zwane software hałzami czy jakieś inne firmy, które wykonują pracę dla innych podmiotów, wykonują pracę dla innych film, zgłaszają się. To są firmy, które dyst mają ich głównym zasobem subprogramiści. Ja nie dystrybują tych programistów, może być też męnerzero, żeby taki POC przygotować. I mają na to na przykład trzy tygodnie dwa miesiące, na którym zależy od projektu, natomiast nie powinno być również kilka miesięcy. I takie projekty są dużo tajsze czasami surowe, nawet po kosztach albo poniżej kosztów i w efekcie jest powiedziane, że przykład da się wykonać na koncepcję, da się zrealizować, wynik jest taki, zrobiliśmy to w ten i ten sposób. Przy produkcji należy pójść tą drogą, ale na przykład unikać różnych rzeczy, które mam wyszły przy okazji. Także to jest taki pewien eksperyment, sprawdzamy czy coś się dzieje, czy coś się uda zrobić i wyciągamy pierwszy wnioski, żeby można było zbudować już taki pełno prawny produkcyjny produkt. Ppełnotrawny produkcyjny to znaczy taki, który później będzie służył innym i czym on się różni od POC? To jest bardzo ważne. Od POCa produkcja różni się tym, że no wieloma rzeczami, ale między innymi. Po pierwsze tym, że zakres jest dużo większych. Czyli w ramach POCa, na przykład jeżeli nie wymamy analitych dotyczącą transakcji internetowych, to możemy w ramach POCa zrobić analitykę, która będzie okrojona i dodatkowo będzie monitorowała tylko jeden określony rodzaj transakcji, na przykład transakcję kartami kredytowymi, albo tylko jakiś tam przelewy gdzieś to. Na przykład cykliczy. I to jest POC, czyli wycinamy sekawałeczek i go robimy, sprawdzamy co się udało. Natomiast produkcja ma już dużo szelszy zakres, czyli w tym przypadku możemy mieć wszystkie nasze transakcje, a dodatkowo analitykę ma być znacznie szersza. Druga rzecz istaka, że produkcja ma działać, a POC ma tylko pokazaj, że da się działać. Czyli na produkcji dorzucamy testerów, solidnych testerów, którzy będą nam sprawdzali tak zwane warunki brzegowe naszych mechanizmów. Wiecie, każdy mechanizm może być napisania tak, żeby zadziałał na przykład na prezentacji, a może być zrobiony tak, żeby zadziałał niezależnie od tego kto do niego siądzie. Na studiach było takie określenie, jeden z naszych prowadzących powiedział, że powinniśmy tworzyć algorytmy, które są idiototporne. Czyli powinniśmy przewidować, że na przykład w przywpisywaniu dajmy na to numer w wartości przelawu. To jest taki bardzo prosty przykład, przywpisywaniu wartości przelawu ktoś może wpisać tekst z liczby. W 50 zł to ktoś będzie chciał przelać część. I taki, w sensie, też napis, cześć. I w przypadku poca nie ma z tym problemu, bo my tylko sprawdzamy czy da się różne rzeczy zrobić, więc my wiemy, że tam będziemy po prostu wpisować liczby. Nie musimy tego, że w sposób walidować, czy tam na pewno ktoś dobrze sprawdził czy nie. Natomiast na produkcji takie rzeczy muszą być już dużo lepiej zrobione. W przypadku big date jak to może wyglądać, no na pocu możemy założyć, że liczby wielkości będą określone. Tak, czyli nie będziemy przyjmować na przykład jakieś tam 10 peta bajtów danych do przetworzenia. W przypadku produkcji powinniśmy założyć, że niestety takie rzeczy będą miały miejsce i się zabezpieczyć przed nimi. Zabezpiecie na lotma, te sposoby albo dorzucając nowe zasoby, albo dzieląc te dane na kawałki, albo wysłając komunikat, że sory twój żądani nie będzie przetworzone i tak dalej. Więc tym się różni produkcja od poca, czyli przede wszystkim zakres, podrógie i diota odporność. I po trzecie, wreszcie, no takie rzeczy już mniej powiedziałbym techniczne, nie jest związane z bezpieczeństwem, ale bardziej ze stetyką. Na przykład, czyli jeżeli robimy anitykę, to na pocu o ten tomatlko być pokazane, że to ładnie fajnie się wyświetla i spoko da się takie dashboardy zrobić z różnymi wykresami. A na produkcji, to już powinny być takie dashboardy z takim system, żeby dało się posadzić anityków, którzy nie znają danego systemu, i żeby oni nie musieli np. tygodnia spędzać na konfiguracji i lataniu za jakąś bazłodanych. Nie dodatkowo, żeby mieli już jakieś szablony dashboardów, tak żeby mogli da tym pracować. To tyle jeśli chodzi o kwestie produkcja wersu spoc, jak to powinno być. Natomiast jak z naszej perspektywy te dwie dwa projekty wyglądają. Przede wszystkim na pocu, i to jest bardzo ważna rzecz, podczas poca mamy my jako inżynierowie dużo większą dowolność i dużo większą inicjatywność i inicjatywę. Czyli my możemy proponować różne rzeczy, my możemy pełnić więcej funkcji, więcej rule. Natomiast w produkcji, podczas takiego już prawdziwego, porządnego dużego projektu, nasze rolę zwykle są mocniej ograniczone. My odpowiadamy z jakiejś kawałek, mamy go zrobić porządnie, mamy go zrobić sposób dopracowany. W przypadku poca zespół jest bardzo często niewielki i my razem młużczymy, siedzimy, wymyślamy. Myślamy architekturę, wymyślamy nowe mechanizmy, implementujemy to i sprawdzamy czy to działa. To jest też bardzo duża różnica i różnie ludzie sprawdzły się w przypadku takich projektów typu proofof concept, a inni w przypadku projektów pełni produkcyjnych, które już trwają latami i tak dalej. I co ja też idzie, która ma być inna i procedury będą inne, czyli w pocu nie musimy mieć szczególnych procedur. My musimy na przykład nie wiem, mówiąc już bardzo technicznie, wrzucać sobie czarkę jakimś naszym prostym sposobem ręcznie na server i sprawdzać czy to idzie. Na produkcji już musi być pełen CI CD, musi być pełen na proceduryzacja i cały proces wrzucania zmian na server i do repozytorem, tak żeby to było dobre, tak żeby to było odporne na chaos. I tym się zgrubsza różnią. Nie spędzajmę więcej czasu nad różnicą POC wersu z produkcja. Powiem tylko, że od tego momentu więcej będę mówić na temat raczej takich produkcyjnych. Chodziąc, ja bardzo lubię te prototypowe projekty, bo tam można się naprawdę wyszaleć twórczo. I ja osobiście należy do osób, które zamiast siedzieć tygodniami i sprawdzać czy kolejny warunek brzegowy został spełniony i realizować kolejne jakieś dopracowanie drobnych rzeczy. Ja wolę tworzyć od zera, tworzyć nowe mechanizmy, architekturle całe systemy, a dopracowanie tych rzeczy wolę zestawić komuś. Nie ukrywam też, że przyjemność frajda i ma to swój urog. Natomiast ja wolę po prostu prototypy. Takie mam charakter i tak lubię bardziej. Różni są ludzie na szczęście niektórzy wolą to, ale większość projektów to jest produkcja. Polecam ci pójść do POC, do prototypuj, jeżeli masz taką możliwość, ale większość to jest produkcja. Jak wygląda organizacja w pracy w takiej produkcji, na takim produkcyjnym, projekcie normalnym? Powiem tak. Może być różnie, bo zawsze jest to ustalane przez menegerów od nowa, od zera. Natomiast prakwie zawsze są do organizacji pracy wykorzystywane, tzw. metodologię z winne. Mówimy tu zwykle bardzo skultowo skrę. Chciałbym skręć to jest dość konkretne pojęcie, to w naszym przypadku ono się często rozmywa i mamy już odmiany tego skrę. Jeżeli nie w ogóle, czy jest skrę, polecam poczytać, a to będzie trochę się dedukować, bo to jest pojęcie masz chwę. Natomiast tutaj tak bardzo pokrótce, pamięci tylko, że przeciwieństwie do bardzo długo trwałej pracy, gdzie musimy zrobić cały projekt i pokazać klientowi. W skramie chodzi o to, że pracujemy i teracyjnie, czyli dowodzimy poszpog wolutku kolejne malutkie fragmenty projektu, ale fragmenty skończone. Czyli nie ma także bardzo długo pracujemy, pracujemy i pracujemy i nie widać efektów i po roku, np. sprawdzamy, czy wszystko działa. Nie, raczej co dwa tygodnie mamy kolejny kawałon tak zrobiony i na bieżąco komunikujemy się skrientem, bo zakładamy też, że różne rzeczy mogą się zmieniać w czasie i koncepcje mogą się zmieniać w czasie. I na tym polega skram, pracujemy taki, to jest takie stała raczej, że pracujemy codziennie i codziennie mamy spotkania związku z tym. Takie daily to się nazywa, które spotkanie daily, na którym każdy powinien dla sztuki odpowiedzieć na trzy podstawowe pytania. Czyli co ja robię odczoraj, co mam za miar robić przez kolejny dzień i jakie mam problemy. Te trzy rzeczy. Standardowe spotkanie ty pudejli nie powinno trwać więcej niż 15 minut i żeby omówić dokładniejsze różne rzeczy, to się umawiamy na kiedy indzie. Tak chodzi o to, żeby był taki przegląd tego, co kto robi i żeby każdy miał standardowo wiedzę na temat tego, co robił pozostaje członkowie projektu Timu zespołu. I skramb jest czymś co obowiązuje raczej w zasadzie wszędzie. Bardzo rzadko się spotyka inna organizacja. Chociaż wewnątrz skrama te modele powiedzmy zwinne, potrafił się różnić. Czyli ja mogę mieć troszeczkę inny niż mój kolega, który pracuje w innym zespole też skramowy. Ok, jak mamy tego skrama przynajmniej raz w tygodniu powinien być coś takiego, to jest dwa baklok refinement i przynajmniej raz w tygodniu powinien być planik. I tu już jest cała kwestia związana z taskami, która wygląda już bardzo różnie. Natomiast co do zasady taski oceniamy punktowo? Punktowo to znaczy niekoniecznie powinno mieć to odniesienie do jakichś dni, niekoniecznie powinno mieć to odniesienie do czasu, tylko jaki jest poziom trudności danego zadania. Ugotzuje cały zespół podczas takiego refinement. Ustalamy taski i dzięki temu później mamy cały baklok, czyli cały tablicę, która jest wypełniona taskami dobrze opisanymi ocenionymi i kiedy planujemy kolejny sprint, czyli takie dwa tygodniowe okres, kiedy pracujemy, to wtedy my już mamy dobrze przygotowane zadania, które tylko możemy wciągać do tego sprintu, dopisować dla niego konkretnych ludzi i wiemy co ile mniej więcej powinno zająć, jaka jest z poświęcłożności i tak dalej. No dobra, to przejdźmy do takich bardziej praktycznych rzeczy. Przychodzisz do projektu i czego możesz się spodziewać, czego powinienę się oczekiwać, że dowiesz się na samym początku. To jest bardzo ważne, dlaczego? Projekt Big Data, tak jak już powiedziałam, najczęściej są elementami większej całości. Najczęściej mamy kontakt z kilkoma innymi zespołami, które coś tam robią, to jest po pierwsze, a po drugie to co my robimy bardzo często też jest bardzo złożone. W efekcie projekt nad którymi siedzimy i nad którym pracujemy jest naprawdę złożony i potrafi być bardzo skomplikowany. Mówię zarówno samym kodzie, samej logicze, ale też np. powiązaniach w projekcie, ale także jeśli chodzi o na zewnictwo, w końcu pracujemy w bardzo wielu branżach, o sam sens tego co robimy. Te projekty bardzo często są złożone. Jeżeli na początku podkniemy się, popełnimy kilka błędów, to może nas to kosztować całkiem sporo, dlatego przygotowałem dla ciebie instrukcja. I czego powinien się dowiedzieć na samym początku? Wej sobie to instrukcja ci tutaj wypunktuje, podlinkowany masz na stronie. Na stronie też zostawiam to instrukcje. Jeżeli w wejdzież nowego projektu wej sobie punkt po punkcie i postaraj się tego dowiedzieć od nowych członków. Na samym początku jest coś takiego, co się nazwa Unboarding, czyli wprowadzanie kogoś dosłownie na pokład, czyli wprowadzanie kogoś do projektu i to powinien być dobrze przygotowany proces. Natomiast bardzo często w ogóle nie jest przygotowany. Więc weź to obietą instrukcję podczas prótygo procesu onboardingowego przejdź punkt po punkcie i zobaczcie się dowiedziałeś tych rzeczy. Jeżeli nie to do pytaj ludzi, którzy tam są. Oni pewnie chcą ci powiedzieć, natomiast bardzo często sami nie wiedzą, jak onboarding powinien zostać skonstruowany. Pierwsza rzecz, zaczynamy od ogół do szczegółów. To znaczy, nie zaczyna i bardzo często lubimy jako programiści. Wchodzić od razów detail. Zaczynamy gadać jakimś szczegule, a człowiek, który nas o czym ty w ogóle gadasz. Nie mam bladę go powięcie o czym my sprojekt, na tym mi wchodzić w jakiś detail i mu przestrzegasz mi przed jakimś błędem. Więc co na samym początku? Na samym początku dowiedz się jak jest ogólny cel biznesowy danego projektu, techniczny, tego gdzie my robimy jako element tej większej całości i dowiedz się jak wygląda architektura, no tej tej tej tej systemu, który tworzysz. Kiedy wiesz, że jak jest ogólny cel i architektura, zacznie schodzić nieco nirzej. Kolejny punkciekiem są poszczególne moduły i repozytoria, które są do nich przypisane. Może być w jakiś moduł, który zaciągadany, może być innym moduł, który przerzuca te dane gdzieś indziej, na architekturze powinienem mieć rozrisowane. Mogą być moduły, które te dane łącznie harmonizują, spajają itd. I te dotych wszystkich modułów powinny być repozytoria. Kiedy pracujesz już, że dwa lata to jest dla ciebie to oczywiste, więc pewnie też nie mówisz o tym innym, którzy dopiero zaczynają, natomiast ci inni powinni się dowiedzieć, że np. do tego moduł jest to repozytorium. Do drugiego jest drugiego repozytorium, ale moduł trzeci i czwarty ma je one repo i ono jest w tym miejscu. Do wiecz się dokładnie jaki moduł odpowiada za jaki moduł odpowiada jaka repozytorium i jak wyglądają kurszowe mechanizmy tam. Ok, fajnie, że pobieramy dane z tej strony, ale pytanie jak to się odbywa. I jeżeli już wiesz jakie są moduły, jakie są repozytory adanych, jakie są kurszowe mechanizmy to już wiesz bardzo dużo, tak więc gratuluję. Możesz przejść do kolejnego punkciku pod tytułem moduły a infrastruktura. Wiesz już jaka jest architektura, jakie tam są moduły, jak ze sobą grają. Mniej więcej masz poczucie gdzie możesz dokładną implementację znaleźć oraz jak to jako działa, to teraz dowiedz się jak te moduły mają się do infrastruktury. Infrastruktury czyli gdzie są przechowywane dane, czy są w tej bazie danych, a jeżeli tak to jakie tam są tabele, jak tam się dostać dokładnie. Jeżeli są gdzieś na jakimś systemie plików rozploszonym, to jak się do niego dostać, czy jest jakiś szel, czy może jest jakaś przeglądarka, czy może potrzebujesz uprawnić, żeby gdzieś dojść. Jeżeli chcemy puszczać doby, to gdzie te czarki lądują i tak dalej i tak dalej. Jak uruchamia się doby? Jeżeli pracujesz ze sparkiem albo z flinkiem, albo z jakimś innym, jak jakimś innym frejmolkiem do przetwarzania danych, to upewnij się. Poprosi kogoś, żeby ci krok po kroku po prostu pokazał, wyjś sobie to repozytorium, w którym to powinno być. Poprosi powiedz mi, pokaż mi jak przykładowy job jest uruchamiany. Krok po kroku zobacysz, notuj to sobie, albo zapisz na ile pija, bo jedno i drugie. Zobaczysz, jak uruchamia się do job, jak się uruchamia do job, to na to, na konsekwencją jest co? Wiedza o tym, jak przeglądać logi, bo sam job nie wystarczy, musimy wiedzieć, gdzie znaleźć logi, na wpadę, gdyby coś wysypało. Jeżeli mamy do czynienia ze sparkiem, to do pytaj, gdzie jest history server? A jeżeli nie ma history servera, to z pytaj co możemy zrobić, żeby ten history server był. Czy był już jakieś próby podejmowane, żeby go utworzyć? I to po tym punkcie ma już naprawdę bardzo solidną wiedzę. Natomiast konieczne, potrzebny jest ci kolejny punkt, pod tytułem linki do kluczowych miejsc. Musisz dobyć linki i zapisz się sobie jakimś pliku, w którym będziesz miał wpisane w punktach. Wszystkie linki do kluczowych miejsc. Repozytorów, serwisów, borda, czyli mam tu na myśli na przykład z zile, bord z taskami. Wszystkiego rodzaju repozytoria z kodem, serwisy, w stylu nie wiem, rabilt, history server, stylu logowanie się do huge, jeżeli robisz na hadupie, na kauderze. To wszystko jest bardzo, bardzo ważne. A także takie serwisy, jak to gdzie rikostować taski na przykład. Chcę, że rikostować od dostęp, chcę, że rikostować o nowego laptopa. To gdzie takie rzeczy? Powinnią się mieć listę tych linków, wpisane w kluczowy miejscu, po to żeby później nie nienękać ludzi i po to żeby przede wszystkim czuć, że masz wiedzę o całym projekcie. Jak to wszystko już ma zrobione, to jeszcze jeden tylko punkt, który jest takim dopełnieniem, czyli jak wygląda tutaj proces deploymentu i jak wygląda praca z gitem. To jest też istotne, chociaż to jest już dopełnienie. To już jest coś dużo, dużo mniejszego, ale warto się dopytać, jaka tu jest w kulturat deploymentu? Jakie mamy środowiska, jakie mamy od środowiska jeszcze zaraz będę mówił? Jakie mamy środowiska? Czy jeżeli chce zdiplować coś na środowisko developmentu, to czy powinnam napisać o tym na czacie? A może to jakoś sobie w kolejkę wklepać, po prostu trzeba się o to dowiedzieć. Jak dyplować i jak wygląda kulturę? Jak technicznie dyplować i jak wygląda kultura? Kolejny punkt, który będzie dotykał tego, czego nie możemy oczekiwać, już po procesie unborlingowym. Do wiele osób wchodzi do projektu i przyjmuje to rzeczywistość, jaka jest. Natomiast powinniśmy kilku rzeczy wymagać i o to, czego powinieneś oczekiwać, jako takie minimum i co warto, powiedzmy, jakoś tam sobie z tyłu głowy zamontować, sprawdzać czy tak faktycznie jest. Najwadzie podstało warzecz, czyli dobrze opisane taski. Co to jest dobrze opisane taski? Dobrze opisane taski, jest wtedy, kiedy ty go bierzesz po dobrze zrealizowanym unborlingu, jeżeli rozumiesz ten unborling przeszadłeś, przeszłaś przez to i wszystko jest raczej zrozumiałe, to bierzesz tak jaka jest taska i nie potrzebujesz już pomocy niekogo z zewnątrz. To jest idealnie opisane taski. Natomiast, jeżeli bierzesz taska i nam jest jedno jakichś skrótowe zdanie, rzucone jeszcze żargonem tego konkretnego projektu, to znaczy, że taski jest do wyrzucenia. Jeżeli oczywiście jesteś początkującymi uniorę, to nie ma co się za bardzo rzucać, ale ja osobiście raczej nie brałbym w ogóle takich tasków i mówią, słuchajcie wróćcie do mnie, jak zostanie opisany lepiej po prostu. Bo ja nie mam zamiaru teraz chodzić przez kolejne trzy dni dopytywać kolejnych osób, o co tu chodzi, tylko dlatego, że ktoś to wypisywał dla niego było wszystko oczywiste. Więc napisał jakieś jedno skrótowe zdanie w nagówku, a w opisie nic nie wpisał. Co warto, żeby było za warte w tasku? Po pierwsze opis, takiego zadania, co należy zrobić, jak to powinno wyglądać. Po drugie, wskazówki, czyli jak to można zrobić, może w jakiegoś klasy można zajść, można w jakichś mechanizm sprawdzić, może można z kimś konkretnym pogadać mertolicznie. I po trzecie, po opisie, po wskazówkach, coś to się nazwa, akceptance, orytyje, czyli klytelia akceptacji. W punkcikach to może być jeden, w punkcie może być kilkanie, trzy, cztery, pięć, laszczej, nie więcej. Punkcików, które musisz spełnić, żeby uznać task za zrobiony. I to jest kluczowa rzecz. Jeżeli masz w punkty, to po prostu później sprawdzasz, czy te rzeczy zostały zrealizowane, jeżeli zostały, to wiesz, że task jest wykonany. I zresztą można się do tego też odwołać, jeżeli jakiś inny członek zespołu powie, oni nie mi się wydawało, nie wiadomo, że to powinno być inaczej, a to to w ogóle to nie jest wystarczające. To typie, że taki akceptance, kreatyje, pokazujesz punkt, po w punkcie jest to zrealizowane, jest. To jeżeli chcesz, żeby to było zrobione inaczej, to kolpanie kolego trzeba to poło zgłosić wcześniej. Jeżeli chcesz ciągle, że to zrealizowane inaczej, to napisz innego taska. Ok, to będziemy myśleć. A ten task jest zrobiony. To jest pierwsza rzecz, którą moglibyśmy wymagać oczykiwać. Druga rzecz, wynika z pierwszej. Skoro mamy dobrze opisane taski, to co? To powinny być taski w ogóle. Zacznijmy od tego, że w ogóle powinny być taski. Bo bardzo często jest tak, że ty robisz jakieś zadanie, które nie jest nigdzie opisane w żadnym zadaniu. Bo ktoś cię na gębę po prostu po prosiu. I nagle się okazuje, że ty robisz 5 zadaj na gębę przez tydzień. Jednocześnie ciągnież jakoś tam jedno zadanie, które masz opisane na tablicy w bordzie, na dziżę. I później przechodzi do sprawdzania i się okazuje, że dwa tygodnie ciągnież jednego taska, która jeszcze nie jest zbyt wymagający i nie za wiele robisz. No tylko, że międzyczasie zrobiliśmy strasznie dużo roboty, która nigdzie nie jest zbisana. A jak nie jest zbisana, to też bardzo często nie do końca wiadomo o co chodzi. I tak dalej, i tak dalej. Więc wymagamy, że mają być taski. Chcę, że bym coś zrobił, sprzyjemność uleć się, by to zrobię, ale napisz mi taska i go dobrze opisz. I trzecia rzecz, design doki. To jest sprzyczyń podobnych dotasków. Design doki mam tu na myśli, bo to może być różne rzeczy oznaczać. DOKUMENT, który określa bardzo często jak konkretna funkcjonalność powinna być zrealizowana. Czyli na przykład, jakie dane dostajemy na wejściu, jakie dane dostajemy na wyjściu, gdzie powinna zachodzić jakaś zmiana. Czyli taki opis, konkretnej funkcjonalności, który nam pomoże albo poprawić coś, albo napisać coś od nowa. W kamiecie design doki też, jak najbardziej możemy tego oczekiwać. I również kilka pomniejszych rzeczy, których powinniśmy wymagać takich jak komunikacja w zespole, jak jak ja piszę, poroszę o, na przykład kół triwiłczy i przejrzenie mojego kodu, to kół triwił jest robione dość szybko. A nie, że przystrzylni się proszę. Takie rzeczy komunikacyjne też jak najbardziej tego możemy wymagać, oczekiwać. I jeżeli coś jest nie tak zgłaszać meneczerowi, a najpierw może samodzielnie rozmawiać z koleżą kamikologią. Dobra, chciałbym przejść do ostatniego punkciku, bo wiesz już dość sporo z tego jak wyglądają nasze projekty. Chciałbym mianowicie powiedzieć o środowiskach. Wspomniałem o tym już podczas punktu instrukcji on podninkowej, ale jeżeli nie robiłeś, nie robiłaś nigdy nic w żadnym komercyjnym projekcie, to może dla ciebie nie być wcale takie oczywiste. No jakich myśl do wiskach pracujemy. Przede wszystkim oczywiście na szemy lokalnym, czyli tworzymy sobie kod lokalnie, ale ten kod później musi zostać wrzucony w formie jakichś na przykład drzarki do na server. I kiedy wrzucamy już nasz kod na server, to mamy najczęściej dostanienie z różnymi środowiskami. Środowisko to jest po prostu jakiś zestaw technologii, który pozwala nam uruchomić nasz projekt. I my możemy mieć trzy różne środowiska dla różnych celów. No myślę, że środowiska powinny być zesamniczo takie same, różnić się jedynie na przykład mocą, tak? Tak, jakimiś zasobami, pojemnością, diskoło i tak dalej. O co chodzi już to macze? Trzy środowiska, pieniędcze z nich to tzw. dev, czyli na czyś środowisko deve loperskie, to jest takie najmniej prilrutetowe środowisko. Tutaj po prostu sobie wdrażamy różne rzeczy, żeby sprawdzić jak to się zachowuje, jak nasze zmiany zachowują się w systemie, jeżeli sprawdzać w całym systemie naprawdę środowisku, prawdziłem serwa, że ani usiemy lokalnie. Więc mamy środowisko deve loperskie, piszemy kod i możemy wrzucić na bieżąco sprawdzić, działa, nie działa, coś się wysypuje, jeżeli tam coś popsujemy, to wiele się nie dzieje. Przemie wezle założenia. Natomiast potem jest drugi środowisko. Jeżeli już popracowaliśmy, zobaczyliśmy, że nasze zadanie zostało ładnie opękane, jest zakończone. Możemy te zmiany wrzucić na środowisko testowe. Środowisko test, środowisko testowe to jest stopień wyżej. I tam już nie możemy robić, co tam się żywnie podoba. Tam już powinny wylądować zmiany, które są nowe jakieś sposób przetestowane, ładnie dokończone. I może do pracy ruszyć tester. Testerczy i człowiek, który zazęcił wchodzi i sprawdza każdy możliwe warunek brzegowy. Mówi wszystko popsuć co się da. Jak on to popsuje, to wraca to do nas i wiemy dokładnie, w którym miejscu się popsuło. A jakie musieli się nie uda ze pszyć? No to super. I co wtedy? Wtedy czekamy. Bo wtedy się zbiera kilka takich zmian, albo kilkanaście, albo kilkadziesiąt, które są ładnie przetestowane przez testera, które są przez nas dobrze napisane. Gwimy, że one działają i teraz pytanie co z tym zrobić wysyłamy to na produkcję. Czyli środowisko testowe to jest środowisko bliwniacze wobec produkcyjnego, tylko że produkcyjne jest już wydatne. Wydatnione na klientów. Ślowisko produkcyjne to jest środowisko skrogo. My wszyscy korzystamy. Zawsze kiedy włączasz, jak ujablikacje, no i sobie na stronę banku. To znaczy, że ta strona banku jest u nich na produkcji. Włącz sobie aplikacje, nie wiem, Spotify to znaczy, że ta muzyka, ta aplikacja jest na środowisko produkcyjnym spotifier. I na środowisku produkcyjnym jest mniej więcej to co na testowym, tylko że przetestowany już przez testerów. Dzięki czemu widzisz, że jest kilka sit. My na środowisku deweloperckim nie mamy stresu, więc możemy testować dużo, więc możemy szybko wyłapywać błędy. Potem jak większość z nich usuniemy to na środowisku testowym. Testerzy zawodowi ludzie, którzy w zajmują się wyłapowaniem błędów sprawdzają jak to wygląda, czy jak to się zachowuje w określonych sytuacjach. A co jeżeli zwiększymy i ludźdanych, tak? Aż w końcu dochodzi do środowiska produkcyjnego, gdzie wszystko powinno być idealnie działające, wedle zamierzenia. I tak działają środowiska. Ok, może jeszcze tylko dosłownie parę słów, nie miałem tego zapalony, ale pomyślałem, że to też może być ważne, ponieważ my pracujemy z innymi ludźmi. Nie tylko z naczyni rami Big Data. My pracujemy, tak jak powiedziałem, na samym początku, w projekcie, który ma jakiś cel biznesowy. Więc my musimy wiedzieć, żeby się dogadać z innymi. My musimy umieć porozumieć się między społami projektowymi. Bardzo często nasze dane wędrują do aplikacji zwykłych użytkowych, łubowych aplikacji. Wkład jakichś wyszukiwarek, to są często wyszukiwalki, ale często też my ładujemy tylko bazy danych, albo danych hultowi danych. W której to wyciągane są dane, żeby móc je przyanalizować, żeby móc zrobić jakieś dashball, ze statystykami, z mapami, z hitmapami, z wykleciekami, z innymi fajnymi życzami. Czyli wygląda to bardzo często tak. My zaciągamy dane surowe, gdzieś tam skądś. Przerabiamy te dane, czyścimy, później przetwarzamy, żeby wyciągnąć z nich jakieś inne informacje, okrejamy i taką esencję umieszczamy w bazie danych, z której to bazy danych, taki zwykłej często relacyjnej. Z której to te dane są brane albo do aplikacji, łubowej albo do dashboardów, analitycznych, albo w ogóle są zostanione w bazach danych i różnie ludzie, którzy umieją korzystać z tej bazy danych, to z nich korzystają. Wkładami sobie wyciągamy jakieś raporty, albo sami sobie robią aplikacje, która zaciąga te rzeczy i tak dalej. Więc my jesteśmy tylko pewną częścią. Bardzo często częścią, która jest wielu narodowa. Czyli my pracujemy w środowisku wielonarodowym, zespół od aplikacji łebowych może być z Indii, zespół dajta sanientystów, może być ze Stanów Zjednoczonych, a Big Data od nas z Polskiej, albo się jeszcze bardziej może to mieszać. Co też wpływa na kilka innych rzeczy, jak np. kiedy pracujemy, kiedy te daily, o których wspomniałem, skromowe mają być. Czasami są rano i taka jest zasada. Czasami są rano 10-8-9, a czasami są o 16-8, bo tylko tak się uda wszystkich spiąt, bo jedni mają 16-8 i nie mają, np. uzmów w tym momencie. I to też są takie kolejne elementy, o których warto wspanić. No dobrze. Na koniec kilka podpowiedzi z mojej strony, co warto robić, jeżeli jako świeżak pojawia się w projekcie. Co zrobić, żeby wykorzystać ten czas? Przede wszystkim odusz, wszystkie rozpraszacze, wszystkie media społecznościowe komórkę, bo to jest twój czas. Teraz możesz nauczyć się bardzo dużo, ale nauczysz się, że je będziesz wykorzystywać ten czas wynajnie. Naucz się wykorzystywać czas wynajnie i sprawdzę, jak różne rzeczy są zrobione w projekcie. Rozmawiając z starszymi starzem, koleżunkami i kolegami, z nich o konkretnych problemach. Pytaj ich, jak różne rzeczy, oni widzą, nawet abstrakcyjne, pewne pojęcia, pewne ideie inżynielskie. Niech oni by ci powiedzą, bo oni mają bardzo często konkretne buksz widzenia na różne rzeczy, które zostały wypracowane w czasie. Szukaj. Szukaj jak to, co ty z nasz, już jakichś mechanizmy, które ty z nasz, są tutaj zaimplementowane. I szukaj różnic przede wszystkim. Ty możesz widzieć, jak nie wiem, z parkiem, ładowanie danych jest zrobione w bardzo prosty sposób. Ok, a tutaj może jest to zrobione troszkę bardziej zaawansowany. Troszkę bardziej poobijane są różne metody. To zobacz, to przejdź cały proces i rozkwiń dlaczego tak. I tak dalej. I notuj te różnice. Notuj, żeby wiedzieć, jak w projektach komercyjnych, prawdziwych dużych, różne rzeczy, różnią się od tego ze stutorialach. I kolejna rzecz, robiąc zadanie, robiąc taska, ciągle mniej przed oczami plan, mniej atomową upaczkę rzeczy do zrobienia. Nie pozwalaj sobie, że je masz taska, którego możesz robić kilka dni nawet. Na to, żeby nie było, że to nie było. Na to, żeby się ojść i tak sobie pozwolić, że ten czas będzie płynął, poprzeglądać kod, zastanowić się, nie dawaj sobie odpłynąć. Ciągle, jeżeli ktoś bycie spiegał, co teraz robisz, co musisz teraz zrobić, żeby wiedzieć, co ja muszę zrobić. Jaką konkretną, takie konkretne rzeczy dąże, która może być podzieloną, cząstką, tego większego zadania. Ale teraz muszę, w zadanie jest zoptymalizować, jak ktoś dooba, żeby je to jechał. A teraz w tym momencie konkretnie wdrażam taką technikę, optymalizację albo w takim momencie sprawdzam tą konkretną teorię, przeszkując tą i tą stronę. I to jest to, co warto robić. Podtrzymujmy, projekty składają się, działy się na produkcyjne oraz prófów koncept, prototypowe. Działamy zwykle metodolagiami z winnymi z kramem. Natomiast co jest tak najbardziej ogólne, najważniejsze to, że Big Data najczęściej jest częścią projektu aniego, jakby całością. Jeśli chodzi o on-boarding, zostawiam cię instrukcję masz podlinkowaną w opisie. Tak jak również to, co powinien być, czy powinien być zrobić wymagać, przy waszem od zespołu, kiedy już tam jakiś czas pracujesz. Powiedzieliśmy sobie dzisiaj o 3 środowiskach, dewanoperckim testowym i produkcyjnym oraz co warto zrobić, żeby projekt cię rozwijał, a nie tylko żeby chwilowo myśleć, że mnie rozwija i wyciągnąć pieniądze. Jeżeli masz jeszcze jakieś pytania, to uderzaj, chętnie nagram osobne materiały albo video albo podcast. Natomiast przypominam, przypominam subskrypcja, ocena w serwisie stymingowym, bardzo ważna sprawa. Dziękuję ci za dacznie ze dzisiaj, a zapraszam też do newslettera oczywiście. Mamy newsletter, fajny newsletter, też link w opisie. A ja dzisiaj się rzegnam życzę powodzenia, mam nadzieję, że spotkamy się kiedyś w jakimś projekcie i mam nadzieję, że jeżeli jeszcze nie jesteś w projekcie big datowym, to niedługo tam wylądujesz tego ci właśnie, życzę, a teraz miłego dnia czy wieczoru. Trzymaj się, cześć!