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.
Wydawanie pierwszej gry we wczesnym dostępie jest skomplikowane. Robienie gier MMO jest skomplikowane niezależnie od posiadanego doświadczenia. A wydawanie pierwszej gry MMO we wczesnym dostępie? Nie inaczej: kompletny chaos. Jak zaprojektować bazę danych, która to przetrwa? Postaramy się odpowiedzieć na to pytanie, bazując na naszym doświadczeniu z Gloria Victis.
Czy zdarzyło Ci się kiedyś przebudować całą aplikację, bo trzeba dodać nowe pole na frontendzie? Albo gdy zmiana organizacji tabel w DB zmieniała całą Twoją domenę? Jak radzić sobie ze zmieniającym się światem i wymaganiami? Jak utrzymywać porządek wewnątrz aplikacji i skupiać się na jej domenie? Jak sprawić, by zewnętrzny świat stał się detalem implementacyjnym? Odpowiedzią jest architektura portów i adapterów.
Na prezentacji opowiem o doświadczeniach z budowaniem aplikacji, gdzie Twoja domena jest najważniejsza i odpowiem m. in. na pytania:
- Co mi to da?
- Jak to zrobić?
- Na co uważać?
- Dlaczego to jest trudne?
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.
