Well, let's see how that #Mastodon thing works out. Find me at (@christopher@networkteam.social) on our own brand new instance.

A few weeks later and we are doing the last finishing touches for a first customer project using this setup. Take a peek at the NPM and Composer packages, they are all public now: . Next step: a demo project to start with a working setup and more docs.

Upcoming: @nextjs with @neoscms in headless mode and full editing experience in Neos UI - driven by frontend rendering in Next.js and content API in Neos. We had a really productive internal barcamp @networkteam for 2 days trying out this crazy idea - results look promising! 🤩.

After Lens (a really nice #Kubernetes GUI) now finally enforces having a Lens account it was time to look for an alternative. I can highly recommend K9s: a CLI based tool to inspect and work with a cluster. I think for me it might be even more effective.

Develop it, Test it, Ship it, Measure it - Building an end-to-end CI. solution for #NeosCMS projects #NeosCon.

Super stoked to be on stage again in a great community. at #NeosCon. Here's the repo for our CI end-to-end setup with #NeosCMS & #Kubernetes. (slides are coming soon).

RT @ClimateHuman: I'm grateful we tried. Man, oh, man, did we try.

RT @rsms: “Rethinking Visual Programming with Go”

RT @n_roettgen: Wir müssen handeln. JETZT! Mit dieser Forderung sind wir nicht allein. Immer mehr unterstützen unseren Aufruf an die Bundes….

I really enjoy using unit tests when developing #Helm charts (using . Writing templates for YAML is hard. This makes it somewhat more enjoyable and enables a fast feedback loop -which is always important. Also: refactoring and safeguard from regressions.

RT @networkteam: Wie verwenden wir #Golang bei networkteam? Und für welche Projekte eignet es sich am Besten?. Neu bei uns im Journal: http….

4. Architectural design is mostly about trade-offs and choosing what you're optimizing for. So if you need to support something for a longer time it's just a very different perspective from optimizing for a short time to market.

3. After all I tend towards more explicit software that is easier to read, is not optimized for the least amount of code and reduces friction as far as possible (e.g. due to framework, tooling, language and dependency updates). But I'm also not optimizing for just being fast 🤷.

2. This is also why I prefer to be sceptic about new dependencies and abstractions. It's better to allow some redundancy and later introduce fitting abstractions if necessary. And you also inherit all burdens of a dependency while maybe not using all of it.

1. There's IMHO no long-term benefit if easy things are low code but once it gets interesting complexity dramatically increases. This is true for most ORMs for example: look, no SQL! But once implicit queries on your entangled entities peform bad it's hard to re-gain control.

For software architectures I see much benefit in striving for a constant/gradual amount of complexity. What does that mean?.

I'm really impressed by after starting to use it for a few projects to add end-to-end tests. There's great engineering in it: robustness, ease of use in CI and CLI. Also debugging and tracing capabilities are already thought of. #Playwright.

RT @networkteam: #Nextjs has many great optimizations for a faster web. Lazy images help to reduce initial page load times and achieve bett….

RT @networkteam: Wir haben 2 neue Posts zum Theme #Docker und #Dockerless in unserem Journal:.