PHPCE 2017 – wybrane prezentacje

W dniach 3-5 listopada 2017 roku, w hotelu Ossa pod Warszawą miała miejsce pierwsza edycja konferencji PHPCE – była to kontynuacja 7 konferencji PHPCon Poland i czeskiej PHP Brno Conference. W ciągu 3 dni miało miejsce blisko 50 prelekcji podzielonych na 3 poziomy zaawansowania (Relaxing, Intermediate i Guru), wśród prelegentów pochodzących z Polski, Niemiec, Wielkiej Brytanii, Czech i Ukrainy znaleźli się Sebastian Bergmann (twórca PHPUnita), Derick Rethans (twórca xDebuga) i Michael Bodnarchuk (autor Codeception – frameworka do testów).

Pierwszy dzień zaczął się z samego rana warsztatami. Natomiast właściwe rozpoczęcie konferencji odbyło się po szesnastej prezentacją How to get the most out of the conference! Później ruszyły równolegle 3 bloki prelekcji.

Niedawno opublikowano pierwszą partię nagrań. Poniżej przedstawiam ich selektywny wybór wraz z oficjalnym opisem i moim komentarzem.

Sebastian Bergmann: Domain Specific Assertions
» (po ang.)

  • Komentarz: Prezentacja o tym jak pisać czytelnie testy. Podejście bazujące na DDD i TDD.
  • Opis: A common language, understood by technical and non-technical stakeholders alike, is essential for good communication in a software project. Combining ideas from Domain-Driven Design and Test-Driven Development, this ubiquitous language can be represented in both production code and test code.
    […] learn how to create tests that are easy to write fast to execute, and deliver highly reliable results. […] gain expertise in the confident and effective implementation of automated tests for their software and learn how to implement custom assertions for PHPUnit to represent the common language of their project in test code.

Matthieu Napoli: Middleware-based architectures

  • Komentarz: Middleware – jako architektura aplikacji web. Świetna koncepcja patrzenia na aplikację.
  • Opis: HTTP middlewares are spreading everywhere since PSR-7, yet they are often seen as an implementation detail for very specific problems.
    After having discovered them with PSR-7, after having written a middleware-based framework and after collaborating on PSR-15, my understanding is now different: middlewares help us better understand and design the architecture of our applications.
    Let’s start again from scratch and work our way up to an architecture entirely built on middlewares: what does it look like and how does it compare to the frameworks we all love?

Mariusz Gil: Discovering unknown with Event Storming
» (po ang.)

  • Komentarz: Sposób na poznanie domeny, którą trzeba zaimplementować.
  • Opis: Event Storming is a lightweight discovery and collaborative learning tool for exploring complex domains and problems. Using Events, the first-class citizens of modern software development, in very short period of the time we can discover, model and visualize flows, aggregates, bounded contexts, business rules and related hotspots, commands, read-models… Event Storming is also a communication platform and knowledge transfer tool you may apply to release into production proper developer’s understanding of the problem, not assumptions or speculations.
    […] learn about Event Storming core concepts, patterns and best-practices you may apply in your next complex project. […] also learn how to use Event Storming on different levels, from big-picture system overview to designing aggregates, commands and merging output of Event Storming session with CQRS, Event Sourcing and Domain Driven Designs implementations.

Mariusz Gil: Modeling complex processes and time with Saga pattern
» (po ang.)
» (po pol., phpers summit 2017)

  • Komentarz: Autor przedstawia sagi jako rozwiązanie problemu procesów w aplikacji.
  • Opis: Time modeling is always difficult, as well as implementing business flows inside complex domains. Long lived transactions which span multiple bounded contexts, possible success and failure scenarios are even more difficult to model, test and implement. Fortunately, we have an answer to this problem! Multiple messages, events, aggregates and bounded contexts? Not a problem, Saga pattern may be very helpful… During this talk you will learn how to model long running business processes which affect many regions inside domains, what are the best possible use-cases and when to avoid sagas.

Nikola Poša: Journey through „unhappy path” – Dealing with exceptional conditions
» (po ang.)

  • Komentarz: Nikola porusza w swojej prezentacji wybrane zagadniania poruszone przez Uncle Boba w Czystym kodzie (rozdz. 7.), np. dlaczego nie używać nulli i kiedy używać klas SpecialCase, ale opowiada nie tylko o tym.
  • Opis: Developers naturally gravitate towards the „happy path” – default scenario in application execution in which everything works as expected, consequently neglecting exceptions and error handling aspect of a software development. This talk provides a comprehensive insight into widely adopted practices and patterns for dealing with exceptional and error conditions. You will learn about writing and organizing custom exception classes, formatting exception messages, component-level exceptions technique, and much more. In a word – Exceptions cheat-sheet. Once thrown, the exceptions should be caught, so you’ll also be introduced with different error handling strategies and concepts.

Alain Schlesser: Uncommon (Ab)Uses of Composer
» (po ang.)

  • Komentarz: Alain opowiada o tym co ciekawego można zrobić za pomocą comoposera wychodząc poza jego domyślne zastosowanie. Autor napisał też artykuł o tym samym tytule w phpArchitect (october, 2017).
  • Opis: Composer is a hugely flexible tool that works reliably on all but the most obscure hosters/platforms. What’s more, it provides a plugin system that lets you pull external code from a repository and have that code hook into the normal Composer execution flow. The logical conclusion is that Composer is used for much more than just pulling in dependencies.
    We’ll start this session with a quick look at the basic mechanisms that make Composer as flexible as it is. Then, we’ll go through some of the more useful and/or exotic examples of how to use Composer for solving problems that it wasn’t really meant to solve.

Grzegorz Skorupa: Eventual Consistency – Designing Fail Proof Systems
» (po ang.)

  • Komentarz: Zachowywanie spójności danych i związany z tym problemy w implementacji, dobrze i szczegółowo omówione. Na początku nagranie jest ciche, ale od 4. minuty jest już ok.
  • Opis: Each day our systems deal with more data, more traffic and more complex tasks. Every large-scale system has to integrate with other internal or external systems. At the same time it should provide up to date information. On the other hand business states high availability and reliability requirements. Those two make designing of such systems difficult. In particular it is difficult to keep your data consistent.
    It often happens that not all requirements can be technically met. Fortunately there are theoretical proofs that define what can and cannot be met in what circumstances. […] The talk […] present[s] some of the data consistency related problems typical to high traffic systems and try to sketch possible solutions. […][It’s also] about: CAP theorem, Eventual Consistency, At Least-Once Delivery and Self-Healing Systems.

Możliwość komentowania jest wyłączona.