User:Pablo Grass (WMDE)/conferences/IJS2020 Munich/day1

Intro

shared IJS and IPC - talks of both available

Keynote, Kim van Wilgen, @kimvanwilgen

continuous delivery is adapted left and right
states that companies which practice CD have 8 times the innovation speed compared to traditional approaches
difficult releases, long weekends are a thing of the past
everyone wants to do a good job - it’s an easy story to sell hence
greenfield rebuild of a complete IT infrastructure (in 2014) for an insurance company, on premise infra → Continuous Delivery, everything was great
another company, trying to repeat the same approaches on a public cloud, yet
- many deployments but no releases
- realized that it is not that applying CD makes you a “unicorn company”, but that having the flexibility of a “unicorn company” is what allows you to practice CD
what creates high performance?
- 4 types of problems:
  - complex, → patterns; have to probe (determine cause-effect), sense, respond
  - complicated, → analysis; sense, analyse, respond
  - chaotic, → no patterns; act (hope for the best), sense, respond
  - simple → best practice; sense, categorize, respond
SW development should be run in experiments. Probe, don’t analyse.
Microsoft chat bot example (adopting racist and sexist learnings)
value of CD is releasing (and being able to get insights from this), “going live” - i.e. showing it to the customer, not having it deployed behind a feature toggle
requires a cultural change
- everything is a prototype - keep on learning and measuring
- instead of a story, have a hypothesis - try to prove it (the things we are uncertain about)
- measuring has to be part of each product
- get rid of unused features
- failure is inevitable - but it’s not a big deal, merely an experiment with an outcome
- imagine the value of code not written, or even removed - stability, security, ability to redesign easier (“software is not an asset, it’s a liability”)
- give mandate to the smart people you hire
- automate all the things - to allow you to go fast in the long run
- learn continuously - and build an environment for people to do it (supportive, …)

The journey to CD is not primarily a technical one but a social challenge of getting the organization aligned behind the shared goal. The reward is high and creating good examples in small, but autonomous subdivisions can help convince others to come on board.

MicroFrontends for MicroServices, Thomas Bröll, @tvdtkb

independent, cross-functional teams compose features end to end
- with MicroFrontends this approach extends all the way into the front end = “micro services in the browser”
need to mitigate disadvantages of micro services
- only “reusable components” are used in various spots
- mentions Bounded Contexts as useful boundaries
Angular as an example
- while the UI may be composed of multiple micro services, they are compiled to a monolith at build time
which technologies exist for micro frontends
- server-side template composition
- built-time integration
  - can not exchange parts independently
  - have to ship everything as one package
- run-time integration
  - frames (mentioned as a historic reference)
  - WebComponents ← focus of this talk
    - handing the client references to JavaScript bundles
WebComponents
- extend the tag names which browsers understand
- CustomElements API, incl connectedCallback method and customElements.define()
- shows that browser support got better over the years. IE still a problem (but there is a polyfill)
- shows the use of shadow DOM to apply base styles to the document and the CustomElements alike
AngularElement
- very specific example
- there does not seem to be a way (?) to “externalize” (cf. https://cli.vuejs.org/guide/build-targets.html#library) angular resulting in payload penalties from having multiple micro frontends this way
Real-world use cases
- “passive” website with active contents
- very specific scenarios

Looking at the example here and our work with Vue, this is interesting to know but is an implementation detail best abstracted behind a framework which makes use of the most efficient approach the respective browser supports of realizing this.

Domain-Driven PHP, Henning Schwentner, @hschwentner

attendance: 32
the usual intro and German jokes
question eternal truths, e.g. DRY
domain story telling as seen in User:Pablo_Grass_(WMDE)/conferences/IJS2019_Munich/day4#Carving_Microservices_out_of_the_Monolith_with_Domain_Storytelling,_Henning_Schwentner_@hschwentner,_WPS_–_Workplace_Solutions
work objects, language, ... - bring that from the real world into the software: on an UI, code and architectural level
programmers are quick to start talking about programming language, DBs, ... and the important questions may go unaddressed
key goal: support the domain and its experts. Make their work easier, fast, more efficient
need to talk to the actual users (collaborative modeling)
- Q (myself): "You said collaborative modeling is developers sitting with domain experts. How do "product people" factor into this? Are they a full replacement for domain experts?"
  - A: (you should not be sitting) they can be good replacements if they know their stuff, but ideally you'd be talking to "the people in the trenches"
- collect nouns [work objects] (statics) and verbs (dynamics), ... - this pre-existing domain knowledge should become ubiquitous language and find their way into the code
in code
- build classes out of work objects, build methods out of their verbs
Q: "do you use the names in the nativ language of the customer?"
- A: Yes. Typically use the original name. There may be reasons for exceptions, but keep in mind that, if you do translations, meaning gets lost and there is a risk to that
Q: "Should you split the sub-domain if it gets too big?"
- A: Yes. And it's ok if this happens over time

Interesting how the slides around the same topic (and example) evolved and how the emphasis was on the collaboration and (human) language aspect now. Important.

Painless UI & E2E Testing and automatic user documentation, Tobias Struckmeier, @tobmaster

attendance: 27
e2e is the most important class of test: testing how a user would see things, "incl. the whole world"
selenium is "still" usually done but with the coming of of more dynamic frontends they are a burden to maintain
why are e2e tests not more popular despite their superiority
- external deps and asynchronity
- performance
- ...
cypress to the rescue
- focus on DX (fix the asynchronity, debugging) by integrating the entire tool chain
shows
```
cy.server()
```
and fixtures
shows
```
cy.get('.selector').debug()
```
mentions the capability to use cypress to take screenshots (
```
cy.screenshot()
```
) and hence the possibility to implement visual regression tests this way
the screenshot capability also lends itself to update screenshots in documentation
running the documentation, e.g. in markdown, could also be used to generate documentation - e.g. https://github.com/bahmutov/cypress-book-todomvc
mentions that the cypress makers discourage the "page" concept and that the tests should emphasize the user behavior
mentions https://github.com/testing-library/dom-testing-library as a way to simplify how one selects elements

We almost picked cypress during wikit development and the more often I hear about it I want to try it in person because each time it sounds almost too good to be true.

The Microfrontend Revolution: Using Webpack 5 Module Federation with Angular, Manfred Steyer, @ManfredSteyer

attendance: 22
"dynamic module federation + angular" (maybe connecting to what we heard earlier)
webpack 5 module federation gives us material to build things in practice which were only theoretical before (like DaVinci's helicopter)
a lookup service could, at run time, collect micro front ends not known at build time
how to load separately compiled, developed resources?
```
await import
```
should make this easy - but it does not work with webpack/angular cli. Everything is assumed to be compiled and optimized together (and chunks are only created from this after that step)
module federation defines roles: host (e.g. a "shell" application) & remote (a micro front end)
- the remote exposes something
- the host defines the remote and imports from it
the RemoteEntry file is built in the remote and contains meta data about it - this is what is loaded in the host. Strong ResourceLoader vibes
parts used in multiple micro front ends can be de-duplicated by defining them as shared
shows https://github.com/angular-architects/module-federation-plugin (fresh off the press) which makes his happen for an angular-cli application
emphasis: this is showing loading a micro front end from another host at run time; this is not merely lazy loading
mentions that shared libraries have version requirements. this can be modeled and configured
Q: do the apps all need to share the same angular version
- A: n+1 would be ok, but a workaround could be to compile to WebComponents and be technology agnostic (could even be a different framework creating those WebComponents)
Q: could the micro front ends share information
- A: It's thinkable but it goes against the idea of micro front ends. Do it responsibly.
Q: Could you give a short example when you would use micro front ends? Starting with a certain team size e.g. or what are your criteria?
- A: Ability to have independent teams would be the top motivation, being able to transition between technologies as a runner up

A smooth presentation (with fat Austrian accent) and next level content which makes one want to try it out right away. What more can you wish for?

BDD revolution - or how we came back from hell, Mateusz Zalewski, @mpzalewski

attendance: 11
shows how behat is used to describe the functionality of an application
goal: reduce ambiguity and "translation mistakes" in how product requirements make their way into the software (cf. what Henning Schwentner said earlier)
the language in the behat scenario might turn out very technical however. It should be understandable to a lay user
also mentions that the test code, though only in a helper code, should show good craftsmanship in order to ease onboarding people on it and refactoring it
introduced page objects to decouple knowledge about technical details (selectors, ...) from the test context, let it describe the business value only
using the same scenarios to implement API and UI tests (with different page objects)
added a decorator(?) which allows to write more natural language by refering by previously mentioned objects (e.g. a shop item) through an article ("it")
despite striving for perfection we should not forget that the applications we build are meant for users and should serve them first
Q: "How do you deal with mocking external services (e.g. payment gateways)?"
- A: interesting topic...
Q (myself): "How do the scenarios find their way into your code repositories? Are they part of the (bug tracker) tickets written by your "product people" and you copy them over?"
- A: usually the developers write the scenarios themself. We are trying to make the product owners take part in that but the developers know which are the key features and prioritize those. We also encourage people to add scenarios to bug reports to prevent future regressions

Sounded like things I assumed to be best practice. The odd clean-up initiative will also be needed in the future. Not sure if the organization structure at Sylius does not allow this but would have been nice to hear a success story where the product team is made part of this.