Seit Anfang Mai ist es nun offiziell: Wir sind „APN Standard Partner“ von Amazon Web Services! Damit sind wir, neben der Software AG, der zweite AWS Partner mit Sitz in Darmstadt. Wie kam es dazu und warum haben wir das auf uns genommen?
Weiterlesen
Nach der Ankündigung einer Managed Kubernetes Lösung auf der re:Invent Ende 2017 hat das lange Warten seit letzter Woche ein Ende. EKS [1] wird generell verfügbar und kann allgemein genutzt werden, wenn auch die EU-Regionen vorerst außen vor sind. Wir wollen uns kurz anschauen, was EKS uns nun wirklich abnimmt und um welche Bereiche man sich selbst kümmern muss.
Es gibt unzählige Möglichkeiten, einen Kubernetes-Cluster selbst zu betreiben. Angefangen beim manuellen Aufsetzen auf die harte Tour [2] über CLI-Tools kube-adm, kops oder andere kommerzielle Angebote kann man aus einer Vielzahl von Möglichkeiten auswählen. Mit EKS (Elastic Kubernetes Service) nimmt AWS uns das Aufsetzen und den Betrieb der Master Nodes ab, inklusive HA-Unterstützung und Integration mit AWS-Diensten.
Andere Public-Cloud-Anbieter stellen mit Google Kubernetes Engine (GKE) und Azure Kubernetes Service (AKS) bereits fertige Managed Kubernetes Angebote zur Verfügung. EKS fällt hier aber ein wenig aus der Reihe. Anders als bei GKE und AKS hat man bei EKS nur die Minion-Instanzen in Form einer oder mehrerer AutoScaling Groups unter Kontrolle. Die Master werden von EKS verwaltet, d.h. Themen, wie Updates, Hochverfügbarkeit und Skalierung können wir delegieren.
The z-index CSS property specifies the z-order of a positioned element and its descendants. When elements overlap, z-order determines which one covers the other. An element with a larger z-index generally covers an element with a lower one.
Working with z-index values in large projects can be really difficult. On a growing project, you can observe the z-index values increasing. At some point it is not uncommon to see values like 99999999. If you want to add a new component with a custom z-index it is hard to test all affected components and its impact. Worst case scenario, you have to go through multiple files and compare z-indices, then build and test again and so on. This can be really frustrating because you end up adding or removing a digit to an already unnecessary high value. This way of handling z-index values leads to many bugs such as components that falsely overlay other components. We encountered the same problem in one of our projects and discovered that a lot of bugs were caused by conflicts between z-index values.
Vor einigen Wochen saßen die unterschiedlichen Teams bei cosee zusammen, um den Bedarf an Entwicklern in den verschiedenen Aufgabengebieten zu besprechen. Neben möglichen Verschiebungen innerhalb der Teams wurde schnell klar, dass neue Kollegen durchaus benötigt werden. Neben den bereits genutzten Veranstaltungen, um mögliche Bewerber auf uns aufmerksam zu machen, wie beispielsweise dem Software Engineering Projekt der TU Darmstadt oder den regelmäßigen TechTalks, entbrannte eine Diskussion über weitere Möglichkeiten.
Wir hatten die Idee, einen Tag der offenen Tür für Studenten anzubieten. Dies ermöglicht es einerseits den Studenten, einen Einblick in ein modernes, agil arbeitendes Unternehmen zu gewinnen, und uns, unsere Arbeitsweise jungen und interessierten Studenten nahe zu bringen und mögliche Bewerber schon im Alltag, außerhalb einer Bewerbungssituation kennenzulernen.
Seit geraumer Zeit gibt es bei uns Brettspielabende. Weil ich selbst sehr begeisterter Brettspielfan bin, habe ich zu einem Neujahrs-Kick-Off mal eine Auswahl von Spielen mitgebracht. Den Kollegen hat das gemeinsame Spiel an diesem Abend sehr viel Spaß gemacht – man hat eine gemeinsame Aktivität abseits der Tastatur und lernt Kollegen aus anderen Teams besser kennen. In der folgenden Unternehmensretrospektive kam deshalb der Wunsch auf, einen regelmäßigen Spieleabend zu initiieren.
Seither finden sich nach jeder ersten Retro im Monat Leute zum Spielen zusammen. Mal spielen alle zusammen ein Spiel, wie etwa im August Captain Sonar, mal teilen wir uns zu kleineren Grüppchen auf (zum Thema „kooperative Spiele“ etwa kamen Robinson Crusoe und Space Alert parallel auf den Tisch). Meist beherrscht ein Thema den Abend; vor allem auch deswegen, weil dadurch die Spielauswahl einfacher wird. Der Begriff „Thema“ ist dabei weit gefasst:
Es kann thematisch im engeren Sinne in den Weltraum oder zu den Wikingern gehen.
Thema kann aber auch ein Mechanismus (Warteschlangenmanipulationsspiele, Stichkartenspiele, etc.) oder
ein aktuelles Event wie die Bekanntgabe der „Spiel des Jahres“-Nominierungen sein.
Wir hatten auch schon Besuch von Brettspiel-Podcastern (Grüße an die Brettagogen und die Bretterburg). Das größte Event in der Brettspielszene war natürlich die letzte Woche zu Ende gegangene SPIEL – die Internationalen Spieltage in Essen. Im Nachgang der Messe wird es bei uns zum wiederholten Mal eine Nachbereitung der Messe geben, auf der diejenigen, die auf der Messe waren, von ihren Eindrücken berichten und ihre Beutestücke zeigen können. Es werden Spieleautoren, Rezensenten, Blogger und jede Menge Spielbegeisterte mit von der Partie sein. Alle, die nicht auf der Messe sein konnten, bekommen so (hoffentlich) einen Eindruck von der Atmosphäre und dem Flair der Veranstaltung; und nicht zu vergessen frischen Spielnachschub.
Mittlerweile trifft sich die ein oder andere Runde auch mal „außer der Reihe“ etwa für eine Runde Descent oder bald Gloomhaven.
So bringen Gesellschaftsspiele auch bei uns Leute zusammen, helfen Team-übergreifend mit allen in der Firma in Kontakt zu bleiben und vor allem gemeinsam Spaß zu haben.
Es fühlt sich völlig natürlich an: Technologieentscheidungen werden von den Entwicklern in den Teams getroffen – nicht durch den CTO oder einen übergeordneten Architekten. Die Entwickler in den selbstorganisierten Teams kennen die zu lösenden Probleme am besten und haben meist auch einen guten Überblick über die möglichen technischen Lösungen. Nach einigen Wochen aber entsteht Streit: Jeder will mitreden. Die Entwickler sind nicht immer alle einer Meinung. Wie viele Standards brauchen wir für alle Teams? Ein Praxisbericht über sinnvolle Rahmenbedingungen für Technologieentscheidungen in selbstorganisierten Teams.
Die Software Technology Group der TU Darmstadt bietet jedes Jahr im Wintersemester das Software Engineering Projekt an. Dabei wird Firmen die Möglichkeit gegeben, Projekte an studentische Gruppen zu vergeben und so potenzielle neue Mitarbeiter kennen zu lernen. Studenten bietet es eine Abwechslung zum theoretischen Studienalltag, indem sie in einer realen Aufgabe praktische Erfahrung sammeln können. cosee nimmt seit einigen Jahren daran Teil. Aus einem der Projekte möchte ich einen Erfahrungsbericht geben.
Retrospektiven sind ein Kernelement agiler Vorgehensmodelle wie Scrum. Wie können Retrospektiven aufgebaut sein, wie halte ich sie lebendig und stelle sicher, dass sie kontinuierlich Verbesserungen hervorbringen? Welche Werkzeuge gibt es für verschiedene Situationen in Retrospektiven?
Wie Konstantin schon in seinem Vortrag Entscheidungen an die Basis! Aber richtig. geschildert hat, werden Entscheidungen bei cosee im bzw. durch das verantwortliche Team getroffen. Dies bezieht sich insbesondere auf die Technologien (Programmiersprache, Bibliotheken & Frameworks, etc.), die für ein Projekt eingesetzt werden sollen. Am Anfang hat dies auch gut funktioniert, da auf diese Weise die betroffenen Entwickler direkt entscheiden konnten, was aus ihrer Sicht am besten für das jeweilige Problem geeignet war.
Bei cosee führen wir alle zwei Wochen eine Unternehmensretrospektive durch. Diese Retrospektiven betrachten die gesamte Firma bzw. das jeweilige Team und sind das zentrale Element unseres Continuous-Improvement-Ansatzes. Der einzelne Mitarbeiter steht nicht direkt im Fokus dieses Feedback-Rituals. Durch Jour Fixes haben wir ein Ritual für persönliches Feedback eingeführt. Weiterlesen