Warsztat developera

75
WARSZTAT DEVELOPERA Gdzie, co i jak Wykład z kursu Digital Frontier – digitalfrontier.pl

description

Slajdy do wykładu wygłoszonego w ramach kursu Digital Frontier - digitalfrontier.pl

Transcript of Warsztat developera

Page 1: Warsztat developera

WARSZTAT DEVELOPERA

Gdzie, co i jak

Wykład z kursu Digital Frontier – digitalfrontier.pl

Page 2: Warsztat developera

Co to warsztat?

Co kryje się pod tym pojęciem?

Page 3: Warsztat developera

Warsztat to:

Miejsce pracy. Niezbędne narzędzia. Procesy produkcyjne i sposoby pracy. Wiedza niezbędna do ich wykonywania.

Page 4: Warsztat developera

Czyli o zaletach dobrego warsztatu

Dlaczego warsztat jest ważny

Page 5: Warsztat developera

Zalety dla nas

Wpływa na jakość naszych produktów. Ułatwia nam pracę. Obniża frustrację. Daje więcej satysfakcji - szybciej, lepiej,

łatwiej. Podnosi nam samo-ocenę. Podnosi bezpieczeństwo.

Page 6: Warsztat developera

Zalety dla innych

Ułatwia współpracę z innymi. Czyni z nas atrakcyjniejszego partnera. Podnosi bezpieczeństwo współpracy z

nami. Jest dobrą wizytówką.

Page 7: Warsztat developera

Inaczej miejscówka

Miejsce

Page 8: Warsztat developera

Moja hierarchia miejsc

Gabinet domowy. Własne biuro. Mały pokój biurowy: 2-5 osób. Średnie pokoje: 5-10 osób. Open plan office (open space): od 10 do

100+.

Page 9: Warsztat developera

Samemu czy w grupie

Page 10: Warsztat developera

Sam (1-5 osób)

Zalety Cisza, spokój, skupienie. Customizacja (brak lepszego słowa)

wszystkiego: światło, dźwięk, temperatura, meble, aranżacja, dekoracja.

Wady Izolacja. Gorsza komunikacja, „wypadnięcie z gry”. Brak pozytywnej rywalizacji. Brnięcie w ślepe zaułki.

Page 11: Warsztat developera

W grupie (5+)

Zalety: Komunikacja i wymiana doświadczeń. Inspiracja pracą innych. Pozytywna rywalizacja.

Wady: Hałas, rozpraszanie, światło, temperatura. Konieczność dostosowania się do innych. Brak możliwości customizacji. Furniture Police.

Page 12: Warsztat developera

Niezbędne wyposażenie

Własny kącik

Page 13: Warsztat developera

Biurko

Duże i szerokie, zdolne pomieścić kilka monitorów, klawiaturę, dodatkowe wyposażenie.

Solidny blat – nie może się uginać pod ciężarem sprzętu i/lub developera.

Materiał, kolor, inne zalety są drugorzędne. Podstawki na monitory, szuflady na klawiaturę

to kwestie indywidualnych upodobań. Ostatnio: regulowana wysokość pozwalająca

na pracę na stojąco.

Page 14: Warsztat developera

Biurko

Page 15: Warsztat developera

Coś pod biurko

Na rzeczy prywatne: Dokumenty. Zupki instant. Napoje

energetyczne. Inne rzeczy. Kable. Bałagan z biurka.

Page 16: Warsztat developera

Fotel

Najważniejszy mebel developera. Inwestycja na lata – nie warto oszczędzać. Zły fotel boli całe życie (oraz rzycie). Domagaj się dobrego fotela od pracodawcy. Jeśli sam się zatrudniasz, kup sobie dobry

fotel – będziesz sobie sam potem wdzięczny. Wygodny, regulowany, podparcie

lędźwiowe, mechanizm „synchro”. Bujanie i resor to nie wszystko – najgorszy

fotel to ma.

Page 17: Warsztat developera

Fotel

Page 18: Warsztat developera

Oświetlenie

Kwestia osobistych preferencji: Słoneczne Żarowe/halogenowe Świetlówki Bezpośrednie Rozproszone

Biura standardowe sprzyjają: świetlówkom i bezpośredniemu oświetleniu.

Biura własne pozwalają na lepsze rozwiązania.

Page 19: Warsztat developera

Oświetlenie

Page 20: Warsztat developera

Cała reszta

Słuchawki! Lodówka, ekspres do kawy, czajnik. Miejsca spotkań. Miejsca wypoczynku/rekreacji. Catering/restauracje/bary/jedzenie na

wynos. Klimatyzacja/wentylacja. Czystość i porządek. Tablice korkowe i suchościeralne.

Page 21: Warsztat developera

Jak to wygląda w praktyce

Page 22: Warsztat developera

Jak to wygląda w praktyce

Page 23: Warsztat developera

Jak to wygląda w praktyce

Page 24: Warsztat developera

Jak to wygląda w praktyce

Page 25: Warsztat developera

Sprzęt i oprogramowanie

Narzędzia

Page 26: Warsztat developera

Hardware

Sprzęt

Page 27: Warsztat developera

Komputer

Microsoft Windows platformą dominującą w tworzeniu gier: Podstawowa platforma do tworzenia gier na

inne platformy. Najwięcej aplikacji i najlepsze (z

wyjątkami). Specjalistyczne aplikacje tylko na Windows.

Specjaliści czasem mogą próbować zaszyć się na OS X, ale ogólna gawiedź musi się pogodzić z Windows.

Page 28: Warsztat developera

Komputer

Developer powinien mieć dobry, wydajny komputer.

Nie musi to być topowa maszyna, ale nie warto też za bardzo oszczędzać.

Liczy się wydajność deva, a nie jego gry (to jest osobny temat).

Cokolwiek, co podnosi znacząco komfort pracy jest dobrą inwestycją: dużo RAM, dyski SSD.

Page 29: Warsztat developera

Komputer

Stacja robocza to nie wszystko – zespół wymaga więcej.

Serwery plików (NAS). Serwery niezbędnych usług (np.

systemów kontroli wersji). Szybka sieć do połączenia wszystkich

nawzajem i z serwerami. Internet.

Page 30: Warsztat developera

Monitory

Jeden to za mało. Dwa to dobrze, a trzy też nieźle.

Wiele monitorów ułatwia pracę i podnosi jej efektywność.

Monitory LCD są tanie, warto zainwestować w minimum 2.

Typ, rozmiar, jakość – kwestia indywidualnych wyborów, najlepiej jednak 22-24”, IPS, czasem z pivotem (dla koderów).

Page 31: Warsztat developera

Peryferia

Dobre myszki, wygodne klawiatury. I znów, średnia półka jest zupełnie wystarczająca.

Drukarka laserowa (kolor kosztuje). Fajnie, gdy ma A3.

Skaner. Dyski zewnętrzne na kopie zapasowe.

Page 32: Warsztat developera

Sprzęt się psuje i starzeje

Ważna jest gwarancja i serwis: Markowe komputery są droższe, ale oferują

lepsze warunku i lepszy serwis (np. NBD). Jeśli mamy ważny projekt, warto mieć

komputer zapasowy. Kopie zapasowe (o tym dalej). Komputery trzeba upgradować – warto

to wkalkulować w rozwój projektu/firmy.

Page 33: Warsztat developera

Software

Oprogramowanie

Page 34: Warsztat developera

Oprogramowanie specjalistyczne

Każda dziedzina ma swoje. Często jest bardzo drogie i nie mamy

wyboru. Warto poznawać alternatywy. Nie każde studio/projekt może udźwignąć

koszty wymarzonego softu – dobrze znać te tańsze/darmowe.

Trzeba umieć „sprzedać” swoje potrzeby w tym zakresie – czasem inwestycja jest bardzo opłacalna.

Page 35: Warsztat developera

Przeglądarka web

Internet Explorer jest najlepszą przeglądarką, aby ściągnąć inną przeglądarkę: Google Chrome Mozilla Firefox Safari Opera

To podstawowe narzędzie do uruchamiania rosnącej rzeszy aplikacji webowych.

Page 36: Warsztat developera

Pakiet biurowy

Najlepszym rozwiązaniem jest Microsoft Office. MS Office produkuje „standardowe” dokumenty. Arkusz kalkulacyjny przydaje się każdemu:

programiście, artyście, projektantowi, producentowi.

Duże możliwości tworzenia pięknych dokumentów.

MS Visio – znakomity program do diagramów LibreOffice – też da radę, choć widać, że to

biedniejszy brat, ale za to za darmo.

Page 37: Warsztat developera

Pakiet biurowy online

Można wybierać: Google Docs (Drive) Zoho Office Suite Office Web Apps

Tanio i każdy może je mieć. Dostępność z dowolnego miejsca. Możliwość łatwego dzielenia

dokumentów, kooperacji oraz publikowania.

Ciągle powiększane możliwości.

Page 38: Warsztat developera

Google Apps

Aplikacje Google we własnej domenie: Poczta (z klientem web). Kalendarz. Komunikator w ramach domeny. Pakiet biurowy (Google Drive). Limit użytkowników: 10 w wersji darmowej.

Nie znam powodów, dla których nie powinno się z tej oferty skorzystać.

Page 39: Warsztat developera

Programy narzędziowe

Idealny rozwiązaniem tej kwestii są pakiety narzędzi portable (przenośnych): Liberkey PortableApps.com Suite

Trywialna instalacja, same się aktualizują. Można je łatwo przenosić pomiędzy

komputerami. Można je mieć zawsze przy sobie (pendrive). Szeroki wachlarz narzędzi – bez problemu

załatwią 99,9% potrzeb.

Page 40: Warsztat developera

Aplikacje portable

Page 41: Warsztat developera

Systemy kontroli wersji

Niezbędne narzędzie w każdej pracy kreatywnej oraz pracy grupowej.

Zapewniają dostęp do poprzednich wersji naszych plików.

Oferują mechanizm wymiany zmienionych plików pomiędzy członkami zespołu.

Zapobiegają/wykrywają/niwelują konflikty w dostępie i modyfikacji tych samych plików.

I mnóstwo innych, o czym później.

Page 42: Warsztat developera

Systemy kontroli wersji

Scentralizowane systemy kontroli wersji (uniwersalne): Subversion Perforce

Rozproszone systemy kontroli wersji, głównie do kodu: Git Mercurial

Page 43: Warsztat developera

Narzędzia kopii zapasowych

Regularne wykonywania kopii w inne miejsce, choćby poprzez narzędzia standardowe.

Zautomatyzowane narzędzia do wykonywania kopii zapasowych (np. przyrostowych).

Systemu wykonywania kopii zapasowych w chmurę (np. polecam CrashPlan)

Systemy archiwizacji kopii roboczych.

Page 44: Warsztat developera

System archiwizacji kopii roboczych Narzędzie, które „śledzi” wybrane pliki/folder

i wykrywa, gdy została zapisana nowa wersja pliku – wtedy robi jej kopię w innym miejscu.

Automatyczny system wersjonowania plików, na którymi pracujemy – możemy nawet mieć wszystkie poprzednie wersji.

Zawsze możemy wrócić do poprzedniej wersji i ocalić zepsuty pomysł, bo mamy dużo kopii zapasowych.

Polecane narzędzie – FileHamster.

Page 45: Warsztat developera

Inne narzędzia

Kodeki – niezbędne do odtwarzania plików mediów oraz do tworzenia ich: K-Lite Codec Pack

Archiwizer – 7-Zip. Antywirus i Zapora. Szyfrowanie dysków (np. Truecrypt). Program katalogujący – jeśli robimy backupy

na fizyczne nośniki. Komunikatory – Skype i Miranda Dropbox, Google Drive, Box Net, etc.

Page 46: Warsztat developera

I dobre warsztatowe praktyki

Procesy

Page 47: Warsztat developera

Porządek w plikach

Podział dysku na partycje, C: nie wystarcza. Folder roboczy, nie desktop. Jasna i czytelna struktura folderów. System nazewnictwa plików (najlepiej stałej

długości) – znamy i przestrzegany. Konsekwencja w używaniu małych/wielkich

liter. Unikanie znaków diakrytycznych. Osobno źródła, osobno rezultaty.

Page 48: Warsztat developera

Zarządzanie plikami

Wygodne narzędzia do operacji na plikach: Total Commander, Altap Salamander.

Umiejętność wykonywania operacji masowych na plikach: wybiórczego kasowania/ przenoszenia/ kopiowania dużych liczb plików.

Umiejętność masowego zmieniania nazw plików.

Page 49: Warsztat developera

Praca z systemami kontroli wersji Systemy te zapewniają:

Synchronizację pomiędzy członkami zespołu. Kopie zapasowe. Dostęp do poprzednich wersji. Możliwość cofania zmian (bliskich i dalekich). Śledzenie zmian. Archiwizacja i tagowanie. Określanie autorstwa. Branch and merge.

Page 50: Warsztat developera

Praca z systemami kontroli wersji Repozytorium (server) i kopia robocze

(klient) Pierwszy checkout, a potem:

Zmiany, a potem commit Update, oby otrzymać zmiany innych

I tak w kółko Tryby:

merge Lock

http://betterexplained.com/articles/a-visual-guide-to-version-control/

Page 51: Warsztat developera

Kopie zapasowe

Sprzęt się psuje, ludzie popełniają pomyłki. Kopie zapasowe mają chronić przed

powyższym. Systemy automatycznej archiwizacji i

wersjonowania. Kopie do innych folderów, na inne dyski. Kopie off-site (wynoszone). Kopie w chmurę (cloud). Kopie proste i przyrostowe. Kopie kopii (np. kopie repozytorium)

Page 52: Warsztat developera

Kopie zapasowe

Coraz więcej danych przechowujemy u innych: Pocztę elektroniczną. Dokumenty. Czasem kod i dane (zewnętrzne repozytoria).

Może zostać pozbawieni dostępu w dowolnym momencie.

Musimy robić sobie kopie zapasowe lokalnie, a te kopie gdzieś sobie dla bezpieczeństwa kopiować.

Page 53: Warsztat developera

Archiwizacja

Nigdy nie wiadomo, kiedy wrócimy do rzeczy sprzed lat.

Dysponuję kopiami prac sprzed 20 lat. Należy stosować standardowe archiwizery. Pamiętajmy, że nośniki fizyczne mają

ograniczony czas życia. Redundancja pomaga w odzyskaniu

danych po latach. Odświeżanie jest dobrym sposobem na

utrzymanie dostępu do starych danych.

Page 54: Warsztat developera

Automatyzacja

Wiele procesów wymaga wykonywania podobnych, albo takich samych ciągów czynności.

To doskonała właściwość do zastosowania automatyzacji.

Tworzenie kopii zapasowych/wersji jest dobrym przykładem procesu, który może być całkiem automatyczny – wystarczy dobrać narzędzie.

Page 55: Warsztat developera

Automatyzacja

Często proces tworzenia czegoś nie dostarcza danych w odpowiednim formacie dla gry.

Trzeba je przetworzyć – wyeksportować, zaimportować, itp.

Czasem jest to kilka etapów, podczas których łatwo o pomyłkę.

Automatyzacja pozwala unikać pomyłek, oraz przyspieszyć proces.

Page 56: Warsztat developera

Automatyzacja

Skrypty wiersza poleceń – pliki .BAT Łatwy język skryptowy do operacji na plikach. Możliwość przetwarzania plików poprzez

narzędzia dające się uruchamiać z parametrami wiersza poleceń.

Języki skryptowe – bardziej zaawansowane języki typu Perl czy Python, które pozwalają na wykonywanie bardziej skomplikowanych operacji na plikach czy wręcz na zawartych w nich danych.

Page 57: Warsztat developera

Automatyzacja

Wykonywanie operacji na podstawie reguł: Narzędzie budujące – make Narzędzie budujące – Apache Ant

Przetwarzają dane wejściowe na podstawie raz zdefiniowanych reguł.

Pozwalają one na tworzenie różnych wynikowych danych na podstawie zadanych parametrów.

Głównie używane do tworzenia buildów – lokalnych lub globalnych.

Page 58: Warsztat developera

Automatyzacja

Ciągła integracja i automatyczne tworzenie buildów dla zespołu wraz z ich dystrybucją: Instant builds Daily/nightly builds

Automatyczne testowanie: Testy jednostkowe Automatyczne smoke tests Testy wydajnościowe

Page 59: Warsztat developera

Identyfikacja wersji

System nazewnictwa powinien pozwalać łatwo rozróżniać podobne dane np. do różnych języków.

Kolejne wersje gry powinny się różnić – proces tworzenia gry powinien automatycznie zmieniać jej oznaczenie wersji.

Warianty powinny być także jasno oznaczane – poprzez umieszczania danych wynikowy w różnych, odpowiednio oznaczonych folderach.

Dobrze oznaczone wersje łatwiej identyfikować (raporty), przekazywać (wysyłka) i archiwizować.

Page 60: Warsztat developera

Zarządzanie dokumentami

Dokumenty współdzielone online rozwiązują wiele problemów: Zawsze jest aktualna wersja. Można współedytować w tym samym czasie. Widać kto i kiedy edytował. Widać co zostało zmienione. Jest historia zmian. Łatwo udostępnia się kolejnym uczestnikom. Daje się przeszukiwać.

Dokumenty online oferują ubogie formatowanie i możliwości, oraz nie wszystkie typy dokumentów.

Page 61: Warsztat developera

Zarządzanie dokumentami

Dokumenty tworzone tradycyjnie można dzielić i zarządzać w systemie kontroli wersji: System z wyłącznością edycji zabezpiecza

przed konfliktami. Jest zawsze aktualizowany. Jest historia zmian. Jest dostęp dla każdego. Nie można go jednak przeszukiwać. Tylko jedna osoba może edytować dokument.

Page 62: Warsztat developera

Baza wiedzy

Nie zawsze zbiór dokumentów w serwisie online czy repozytorium jest dobrym sposobem na dokumentowanie wiedzy.

Jest zapewne najprostszym do wypełnienia, ale nie do użytkowania.

Wiedza na temat gry czy procesów produkcyjnych może być lepiej przedstawiona w formie wiki.

Wiki jest trudniejsze w utrzymaniu (szczególnie oparte o mark up) i ma ograniczone (znów) możliwości formatowania.

Page 63: Warsztat developera

Zarządzanie procesami etapowymi Wiele procesów produkcyjnych w grach jest

wieloetapowych, gdzie każdy etap wykonywany jest przez różnych ludzi.

Musi istnieć dobry mechanizm przekazywania sobie prac pomiędzy etapami – np. poprzez umieszczanie ich w odpowiednich folderach repozytorium.

Kolejni wykonawcy muszą wiedzieć, że czeka ich nowa praca – mogą sprawdzać foldery, ale też można zorganizować jakiś system informowania się o zakończeniu etapu.

Page 64: Warsztat developera

Zarządzanie procesami etapowymi Można trzymać wspólny arkusz kalkulacyjny, w

którym oznacza się statusy odpowiednich obiektów.

Można też mieć tablicę z karteczkami, które wędrują do odpowiednich przedziałów informując kolejnych wykonawców, że czeka ich praca.

Czasem owa praca to akceptacja. Można zrealizować tablicę w formie

elektronicznej, choćby w systemie Trello.com Warto poczytać o metodyce Kanban.

Page 65: Warsztat developera

Zarządzanie swoim czasem

Pamięć jest zawodna – lepiej jakoś zapisywać, co chcemy robić.

Najprostsze są choćby listy to-do. Większość z nich to aplikacje webowe,

dostępne z każdej przeglądarki i aplikacji mobilnych.

Nierzadko mogą pomóc nas w zarządzaniu małym i niemałym zespołem.

Page 66: Warsztat developera

Zarządzanie swoim czasem

trello.com

todoist.com

basecamp.com

teuxdeux.com

Page 67: Warsztat developera

Praca efektywna

Prokrastynacja Stwierdzenie

zjawiska Walka z nim

Flow Walka z rutyną,

znudzeniem i wypaleniem.

Page 68: Warsztat developera

Zbieranie danych

Zbyt wiele rzeczy ocenianych jest „na czuja” i na podstawie tych obserwacji wyciągane są wnioski i wprowadzane zmiany.

Często obserwacje są błędne, obarczone błędami psychologicznymi.

Skuteczność wprowadzonych na skutek błędnych zmian oceniania jest ponownie błędnymi obserwacjami.

Problem pogłębia się zamiast znikać.

Page 69: Warsztat developera

Zbieranie danych

Znacznie lepszy sposobem jest zbierania twardych danych, opartych na obiektywnych pomiarach (tzw. metrics).

Obiektywne dane nie oznaczają, że wyciągniemy właściwe wnioski, ale możemy ponownie zweryfikować rezultat w oparciu o obiektywne dane.

Obróbka statystyczna może być trudna, ale tu możemy poprosić o pomoc.

Page 70: Warsztat developera

Zbieranie danych

Metrics nie muszą dotyczyć gry, ale także mogą dotyczyć procesów produkcji.

Możliwość śledzenia czasów produkcji podobnych elementów umożliwia obiektywne stwierdzenie wpływu udoskonaleń procesu. Można też wykryć zjawiska, które wpływają na zakłócanie procesu, czy potencjalne wąskie gardła.

Page 71: Warsztat developera

Autopromocja i nauka

Pokazujmy innym w zespole, co tam robimy: Róbmy snapshoty. Pokazujmy je i dyskutujmy. Chwalmy się i pobudzajmy zdrową rywalizację. Mentorujmy młodszym

Uczmy się od innych w zespole: Róbmy regularne przeglądy naszych prac. Patrzmy co ktoś zrobił i jak. Pytajmy się i uczmy od starszych.

Page 72: Warsztat developera

Dokumentowanie projektu

Chodzi o dokumentowanie tego, co się w projekcie działo.

Zapamiętywanie zadań z systemu zarządzania nimi (fajna historia zadań).

Robienie screenshotów i filmików regularnie co jakiś interwał, aby móc odtworzyć proces przemiany gry.

Archiwizacja co jakiś czas gry w jej aktualnym stanie – znów fajna możliwość prześledzenia zmian.

Zdjęcia z pracy i zabawy – fajnie do nich wrócić po latach.

Page 73: Warsztat developera

Co generalnie warto znać

Wiedza

Page 74: Warsztat developera

Wiedza

Stale pogłębiana wiedza na temat specyficznych narzędzi i procesów w naszej dziedzinie.

Zapoznawanie się z nowymi/innymi narzędziami, nawet jeśli ich nie używamy w danym momencie.

Podglądanie pracy innych, wymiana doświadczeń.

Gromadzenie referencji, które mogą się na przydać w pracy, czy współpracy z innymi.

Page 75: Warsztat developera

Wiedza

Wyrażenia regularne – nieocenione w zamianie nazwa plików, wyszukiwaniu plików czy bardziej skomplikowanych operacjach na tekstach.

Składnie skryptów .BAT Co to jest CSV, XML oraz JSON i dlaczego w tym

ostatnim warto przesyłać dane. Co to są bazy NoSQL i dlaczego fajnie w nich

trzymać dane do analiz (metrics). Fajnie wiedzieć coś o metodykach zwinnych

(agile). Jak zamieniać nasze dokumenty na PDFy!