After talking about how to define DTOs in the last article, this article focuses on how we can go even further and use those DTOs to render Django components.

The basic idea of using DTOs is to separate data from business logic and app-specific functionality. This is especially interesting in cases you need to pass data to a different layer or receive data from a different service.

Thanks to Corona, I finally have time to play around with new recipes in home office lunch breaks on a daily basis. One of my favorite creations so far is my take on the "Mushroom Burger".

After my first attempt into iOS app development was already that big of a success, I'm proud to announce that we launched my second app today: "Event+". It's basically a digital, filterable version of the book "Veranstaltungsformate im Vergleich" my father wrote.

I hate scrum. It's expensive, unflexible and never works as good as it might sound on paper. At least not in a reality where you have a released product that is used by real customers. But not everything is bad about it: Retrospectives, for example, are a really useful tool for teams.

I guess we've been all there at one point: You started out with one (Django) application, new requirements came in and you added more models and then more applications and somehow everything got out of control as there was no clear definition of the application hierarchy. Worry no more - this article might be your rescue.