I had the problem that every Docker Desktop update failed and I had to reinstall Docker Desktop. Now I have solved it. The problem was that when ProcessExplorer is running in the background, Windows can't delete the services, and only marks them as "will be deleted" - which happens on the next restart of Windows.
If ProcessExplorer is closed just before the update process, then the Docker desktop update will run without problems. I guess there are more tools like ProcessExplorer which will prevent the Windows service deletion, but this was the reason on my machine as I'm always starting the ProcessExplorer with the Windows start.
Maybe this information will help someone else.
iBiber - About software development
A blog about software development topics like: * System architectures * Processes * Helpful tools * and also some funny things
Dienstag, 12. Mai 2020
Freitag, 8. Mai 2020
Design principles Wiki
Are you interested in software design principles like SOLID, KISS or High cohesion & low coupling? You want to know in which context a principle is useful and which other principles are related or contrary to it?
Then this Principle-Wiki will be helpful: http://www.principles-wiki.net
Then this Principle-Wiki will be helpful: http://www.principles-wiki.net
Mittwoch, 17. Juli 2019
Micro frontends - extending the microservice idea to frontend development
I think this article "Micro Frontends" (by Cam Jackson on martinfowler.com) is a great resource to get familiar with the idea about Micro frontends as we want to build it in our next project.
It gives an overview about when/why Micro frontends are useful, explains how these integration approaches are working by an example:
It gives an overview about when/why Micro frontends are useful, explains how these integration approaches are working by an example:
- Server-side templates composition
- Build-time integration
- Run-time integration via
- iFrames
- JavaScript
- Web Components
Code ownership - Quality vs Flexibility
Martin Fowler describes three different models of code ownership:
- Strong code ownership
"Strong code ownership breaks a code base up into modules (classes, functions, files) and assigns each module to one developer. Developers are only allowed to make changes to modules they own ..." - Weak code ownership
"Weak code ownership is similar in that modules are assigned to owners, but different in that developers are allowed to change modules owned by other people. Module owners are expected to take responsibility for the modules they own and keep an eye on changes made by other people ..." - Collective code ownership
"Collective code ownership abandons any notion of individual ownership of modules. The code base is owned by the entire team and anyone may make changes anywhere ..."
Freitag, 5. Juli 2019
Flaky tests (non-deterministic tests) are useless
"Non-deterministic tests have two problems, firstly they are useless, secondly they are a virulent infection that can completely ruin your entire test suite. https://martinfowler.com/articles/nonDeterminism.html" Source Twitter
I think that statement summarizes the problem very well and the linked article by Martin Fowler explains that statement very well - so I would recommend to everyone to read the article. Although it was written in 2011 the listed kind of problems are still the same.
I think that statement summarizes the problem very well and the linked article by Martin Fowler explains that statement very well - so I would recommend to everyone to read the article. Although it was written in 2011 the listed kind of problems are still the same.
Remote Mob Programming und Mob Programming
Über diesen Erfahrungsbericht (Remote Mob Programming - Home but not alone) im Rahmen eines Podcasts bin ich auf das Thema Remote Mob Programming gestoßen.
Die Podcast-Folge selbst ist empfehlenswert, dort verlinkt sind aber auch diese Ressourcen zum Nachlesen:
"All the brilliant people working on the same thing, at the same time, in the same space, and on the same computer"
Das wichtige an dem Verfahren ist die Kommunikation und der Erfahrungsaustausch, sowie das gemeinsame Treffen von Entscheidungen - sowie das wissen, warum diese Entscheidungen getroffen wurde. So sind auch diese Aussagen zu verstehen (siehe Three constraints for introducing Mob Programming):
Ein weiterer (mir) wichtiger Punkt ist, dass man auch gemeinsam Dokumentation schreibt - ich kann mir vorstellen, dass dadurch bessere und relevantere Dokumentation entstehen kann.
Die Podcast-Folge selbst ist empfehlenswert, dort verlinkt sind aber auch diese Ressourcen zum Nachlesen:
- https://www.innoq.com/de/blog/remote-mob-programming/ (Auflistung der Rahmenbedingungen in Deutsch)
- https://www.remotemobprogramming.org/ (Die gleiche Liste in Englisch mit Erklärungen dazu und weiteren Ressourcen)
"All the brilliant people working on the same thing, at the same time, in the same space, and on the same computer"
Das wichtige an dem Verfahren ist die Kommunikation und der Erfahrungsaustausch, sowie das gemeinsame Treffen von Entscheidungen - sowie das wissen, warum diese Entscheidungen getroffen wurde. So sind auch diese Aussagen zu verstehen (siehe Three constraints for introducing Mob Programming):
- It’s a behaviour change from “I have an idea, give me the keyboard” to “I have an idea, you take the keyboard”
- For an idea to go from your brain to the computer, you have to use someone else’s hands - [Llewellyn Falco]
Ein weiterer (mir) wichtiger Punkt ist, dass man auch gemeinsam Dokumentation schreibt - ich kann mir vorstellen, dass dadurch bessere und relevantere Dokumentation entstehen kann.
Dienstag, 11. Juni 2019
Architecture decision record (ADR)
In a side note of a podcast I found the topic "Architecture decision record (ADR)".
The blog-post of thinkrelevance "Documenting Architecture Decisions" gives a very good motivation about why you should care about this topic and what ADRs are.
I'm on the same page that it makes sense to write ADRs into the repository for open source projects. Maybe it is also true for an enterprise company. But I think it maybe easier to start with wiki/confluence articles in that environment - especially one pro is that you can use images and not only text.
Further I found this github-repro, which provides an overview and some templates. But for me it looks like that it is a good advice to start with the simplest version of Michael Nygard, because for me is the argument that it should be a "short text file" important, because it shouldn't take much time to get the point of the decision and why it was made.
The blog-post of thinkrelevance "Documenting Architecture Decisions" gives a very good motivation about why you should care about this topic and what ADRs are.
I'm on the same page that it makes sense to write ADRs into the repository for open source projects. Maybe it is also true for an enterprise company. But I think it maybe easier to start with wiki/confluence articles in that environment - especially one pro is that you can use images and not only text.
Further I found this github-repro, which provides an overview and some templates. But for me it looks like that it is a good advice to start with the simplest version of Michael Nygard, because for me is the argument that it should be a "short text file" important, because it shouldn't take much time to get the point of the decision and why it was made.
Abonnieren
Posts (Atom)