Hi zusammen,
diese Woche gibt's zwei neue Videos :-) In beiden geht's um wissenschaftliche Arbeiten. Ich hoffe, dass Ihr meine Tipps bei der Vorbereitung und dem eigentlichen Schreiben hilfreich findet.
Hi zusammen,
hier ist ein neues Video, in dem ich mit Sebastian Hahner @skate702, einem Doktoranden vom KIT und schon sehr erfahrenen Youtuber über das Promovieren spreche.
Wer schon immer mal wissen wollte wie Doktoranden ticken oder selbst überlegt zu promovieren sollte unbedingt mal reinschauen.
Das Interview zu führen hat echt Spaß gemacht! Vielen Dank an Sebastian, war echt ne super Erfahrung, zusammen mit Dir zu sprechen!
Hey zusammen:-),
ich hab grad nach langer Zeit wieder die Folge Big Ball of Mud von Podcast Corecursive gehört.
Hier ist der Link: corecursive.com/22-big-ball-of-mud-architecture-an…
Corecursive ist generell ein guter Podcast, bei dem es um viele verschiedene Informatikthemen geht.
Manche Folgen sind besser, manche weniger. Aber Big Ball of Mud ist exzellent.
Es geht um Monolithen und wie man deren Robustheit und Skalierbarkeit verbessert, aber auch um Softwarearchitekturen, die man in der Cloud findet allgemein.
Super ist z.B. die Klassifizierung der Isolationsformen:
- Isolation in time (also synchrone vs. asynchrone Calls)
- Isolation of state (z.B. verschiedene Datenbanken / Speicher für verschiedene Microservices)
- Isolation of space (hauptsächlich Isolation der Deploymentziele)
- Isolation of resiliency (andere Teile der Applikation funktionieren auch wenn bestimmte Teile ausfallen)
Zu letzterem erwähnt er als ein übliches pattern, um dem zu begegnen, den circuit breaker. Vom Prinzip ist das ein kleiner Service, durch den alle Requests, die an einen Service gerichtet sind, durchlaufen. Falls der dahinterliegende Service einen Fehler zurück liefert, dann unterbricht der Circuit Breaker alle weiteren Requests und sendet dem Aufrufenden direkt eine Fehlermeldung zurück. Der "Stromkreis" oder circuit ist dann gewissermaßen offen. Nach einer Weile (einem timeout) geht er in einen halboffenen Zustand und prüft, ob ein einzelner Request wieder vom Service fehlerfrei angenommen wird. Falls ja, geht er wieder in den offenen Zustand. So verhindert man, dass ein ohnehin schon überlasteter Service total zum Erliegen gebracht wird.
Generell ist es eine gute Idee, seine eigene Architektur dahingehend zu hinterfragen was passiert wenn ein bestimmter Teil ausfällt. Eine typische Frage, die auf die Plausibilisierung der Robustheit abzielt. Macht man genauso in Security, wo man fragt was passiert wenn der Angreifer da rein kommt oder ein token dort geleakt wird etc.etc. Also in "abuser" stories oder "failure" stories denken.
Ok, das nur kurz als Update. Werde ab und zu immer mal was posten, wenn mir irgendwas interessantes begegnet. Meldet Euch, wenn Ihr mehr Details oder ein Video dazu haben wollt.
Viel Erfolg weiterhin!
Sebastian
Hi, ich bin Sebastian, Professor für Informatik an der Hochschule für Wirtschaft und Recht Berlin (HWR). Hier ist mein Profil an der HWR: www.hwr-berlin.de/hwr-berlin/fachbereiche-und-bps/…
Seit vielen Jahren bin ich im IT-Bereich tätig, sowohl in Wirtschaft und Wissenschaft. Neben der Informatik und der Mathematik liebe ich es, meine Erfahrungen zu teilen und Menschen zu begeistern.
Auf diesem Kanal möchte ich allen Interessierten, z.B. Studienanfängern oder zukünftigen Coden, Einblicke in die (wissenschaftlichen) Grenzen der Informatik und Mathematik sowie die Auswirkungen auf unsere Wirtschaft und Gesellschaft geben. Es kann also sehr weitgefasst oder sehr speziell werden.