V edycja otwartej, darmowej konferencji
poświęconej zagadnieniom informatycznym
poświęconej zagadnieniom informatycznym
18 listopada 2017, Gliwice
So where is your documentation? It should has been done yesterday! – There is no documentation in Agile – replied a lazy developer. – “Working software over comprehensive documentation” – explained another agile one. – Let’s create a change request – PM rubbed his hands – you may generate a Javadoc! – Isn’t our code self-documenting, Uncle? – asked an XP developer. – No document unless it's need is immediate and significant – confirmed Bob. How many times have you heard such conversation? Probably you are not surprised with a common reluctance concerning software and code documentation. However, do you feel comfortable with Github projects having poor readme.md? This topic is addressed to developers who want to forget about documentation and return to the code. It may also interest people who feel that the time of docx files faded away. I will talk about modern and diverse methods or documentation replacements. I will show among others how to: create living documentation which won’t be outdated tomorrow; replace user stories and executable specifications with tests (still clear to business people); generate documentation elements without waffle; create graphs and diagrams without legacy UML; document API without Swagger’s hell of annotations.
Jeśli jesteś jednym z tych programistów, którzy piszą testy, bo uważają je za przydatne i chciałbyś jeszcze udoskonalić swój warsztat, ta prezentacja jest właśnie dla Ciebie.
Jeśli jesteś tym, którego irytują testy, albo któremu testy przeszkadzają w pracy, ta prezentacja również jest dla Ciebie.
Będę mówić o tym, jak możesz ocenić, czy testy przynoszą jakąś wartość i jak możesz pisać testy, które przynoszą taką wartość, jakiej w danym momencie potrzebujesz.
Przedstawię techniki projektowania testów na realistycznych przykładach zamiast poprzestać na zakresach liczb.
Dowiesz się, jak możesz sprawić, aby testy z uciążliwego obowiązku stały się pożyteczną częścią Twojej pracy.
Stereotypowym skojarzeniem na hasło „game development” jest wizja programistów tworzących wydajne silniki, designerów obmyślających miodne rozgrywki, artystów, animatorów i dźwiękowców wspólnie tworzących porywające scenerie. Naturalnie w skojarzeniu tym jest mnóstwo prawdy. Jednak w dzisiejszych czasach, kiedy tworzenie i wydawanie aplikacji jest coraz prostsze, a konkurencja większa niż kiedykolwiek wcześniej, na znaczeniu zyskują inne, dodatkowe mechanizmy, często ukryte nieco w głębi, czasami zupełnie niewidoczne dla użytkownika – gracza. Wraz z dynamicznym rozwojem koncepcji chmury publicznej, początkowo zaadoptowanej głównie przez aplikacje biznesowe, coraz częściej spoglądali w jej stronę także twórcy gier. Okazuje się, że dostępne technologie i sposoby tworzenia oprogramowania w chmurze otwierają nowe możliwości, z których na równi korzystać mogą zarówno mali, niezależni developerzy jak i giganci branży uzyskując przy tym bardzo wymierne korzyści. Pewne gatunki gier wręcz nie są w stanie obyć się bez takiej klasy mechanizmów.
Co takiego dokładnie można dzięki chmurze uzyskać, jak rozpocząć pracę z chmurą żeby efektywnie wykorzystać ją w całym procesie tworzenia, wydawania i utrzymywania gry? Postaram się rzucić nieco światła na te zagadnienia podpierając je rzeczywistymi przykładami i informacjami wprost od developerów.
Istnieje dosyć silny stereotyp programowania w IT jako pracy nudnej, lecz dobrze płatnej, z kolei pracy w gamedevie jako interesującej, ale wykańczającej. Spróbujemy zmierzyć się z tymi stereotypami i spytać ludzi, którzy pracowali na obu frontach, jak jest naprawdę? Co skłoniło ich do zmiany stron i jakie były plusy i minusy pracy w każdej z tych branż?
