Am Beispiel von Exasol.
Aus einem lokalen Monolithen Teile herausschneiden und verteilen ist komplex. Zumal mit jeder Verschiebung von Code an anderer Stelle neue Probleme auftreten können.
Das Herausfinden der passenden Rechte für eine Rolle ist ganz schön schwierig.
Wollte gestern openssh auf einem AMI deinstallieren, schlug fehl.
Einfach nur aktivieren und dann ist die Verbindung verschlüsselt. MITM ist damit allerdings immer noch möglich.
Sehr interessant.
Bäääh. Dem folgt ein ganzer Rattenschwanz an Problemen.
Diese kann auch mit nicht existenten CMKs konfiguriert werden und dann bekommt man ganz komische Fehlermeldungen.
Mir hilft es die Agenda zu sehen, statt das Arbeitsmaterial gezeigt zu bekommen und die Agenda zu hören.
Ich habe gelernt, dass beim Erstellen eines ADRs ein schmales Template + ISO 9126 sehr gut leiten.
Unliebsame Aufgaben verleiten mich gern zu prokrastinieren. In solchen Momenten hilft Gruppenarbeit oder regelmäßige "Syncs".
Ich dachte, es wird nicht lange dauern. Jeder Iteration hat 6mins gedauert. Im Endeffekt musste ich nach 2h abbrechen, weil meine Zeit zu Ende war. Am nächsten Tag auf 1min Feedback innerhalb von 6mins optimiert. Nach 5 Iterationen, also ca. 10mins war ich fertig.
Manchmal müssen auch crossproject Tests sein. AMI Packer Lauf und Terraform KMS Policy Definition.
Den ganzen Tag kleine Versatzstücke für die Woche zusammengesucht und an einem Konzept weitergearbeitet. Kleinteilige Konzeptarbeit ist am schwersten.
Aus einer Beobachtung gelernt, es lohnt sich während einer Konferenz den Status des Mikrofons im Auge zu behalten.
Heute mit APEX und dem aktivieren des REST Listeners zu tun gehabt. Ein Krampf dazu sinnvolle Dokumnetation zu finden.
Heute mit IBM Netcool versucht unser Monitoring zu integrieren. Die UI ist gelinde gesagt etwas aus der Zeit gefallen.
Ich habe die Akzeptanzkriterien nicht im Blick gehabt und zuviel implementiert. Habe es dabei etwas Mocking in Python geübt, den Code allerdings wieder weggeworfen.
Heute einen halben Tag für eine Sache Zeit gehabt. Dabei drei Unterbrechungen, so dass es sich im Endeffekt wie 2 Stunden angefühlt hat.
Wir haben eine Logik für die Adressung von KMS Keys implementiert. Diese fällt auf einen Generalschlüssel zurück, wenn kein passender Schlüssel gefunden wird. Zudem ist die Verwendung und Erstellung eben dieser in verschiedenen Repos getrennt umgesetzt. Infolgedessen wird nun nach den ersten initial erstellten Schlüsseln, nur noch überall der Generalschlüssel verwendet.
Habe zu lange an einem Weg festgehalten, statt eine Heuristik in Betracht zu ziehen.
Peu à peu Domain um Domain freigeschaltet, um renovatebot ohne Fehler zum Laufen zu bekommen.
Haben heute eine Planskizze für ein Projekt abgehakt und einen wichtigen Meilenstein genommen. Unbekannte Ideen, haben wir gelöscht und verworfen und nicht ins Backlog gepackt. Alle waren einverstanden. "Lean" kommt langsam.
Wieder erfahren, dass TDD den erreichten Fortschritt bei einer Implementierung sehr gut sichert. Zumal, wenn spät noch delikate Fehler erkannt werden. Somit ist das Refaktoring im Nu erledigt ;).
Wir haben letzte Woche zwei Tage einen PoC gemacht. Diese Umsetzung hat sich als nicht nachhaltig erwiesen. Dann machen wir heute noch einen. Waren ja nur zwei Tage. Zwei Tages Experimente.
Ich wußte, dass wenn ich bis 16 Uhr mit meinem Skript nicht fertig bin, dass ich dann mit dem harten Termin um 18:00 höchstwahrscheinlich bei dem kleinsten Problem nicht fertig werde und unbefriedigt abbrechen muss. War leider genau so.
Eine geplante Vorstellung der Arbeitsergebnisse bringt eine gewisse Verbindlichkeit.
Stündliches rotieren hat alle bei Laune gehalten. Kann wiederholt werden.
Wir haben vor einem 2 Tags PoC einen Taskbreakdown gemacht und etliche Lösungsvarianten angeschaut. War sehr effektiv.
Ich habe versucht mir einzureden, die Tests später machen zu können. Geht aber dann gibt es eben öfter mal dumme blöde Fehler, die dann peinlich sind.
Ein kompliziertes Berechtigungsschema abzugleichen und zu dokumentieren ist schwierig. Warum also nicht, aus der Dokumentation die Implementierung generieren?
Mal sehen, ob es sich als Schnapsidee herausstellt.
Was gut war, wird gern wiederholt.
Maintenance zu automatisieren fühlt sich gut an - erste Schritte.
IAM Policy und Bucket Policy debugging ist schwer, zumal noch winzige Asynchronitäten dazu kommen.
Die Feedbackschleife wieder etwas kleiner zu machen, macht produktiv.
Heute aus Versehen einige ungesicherte Arbeitsergebnisse von zwei Tagen gelöscht. Kein Backup --> kein Fallback.
Heute Pipeship mit der Auslieferung in die zentrale Dockerregistry ausprobiert und eingesetzt. Sehr smooth.
Ich erkenne mehr und mehr, dass Überforderung in Situationen deutlich - auch für mich selbst - von großer Unsicherheit begleitet wird. Gedanke: Eventuell kann über eine Selbstbefragung zu Selbstsicherheit Aufschluss geben?
Ich bin frustriert, wenn ich 1h für eine Iteration warten muss (Aufsetzen einer Oracle DB in AWS).
Habe heute Feedback zu gestrigem Meeting gegeben. Ich hätte es auch besser vorbereiten sollen. Wie einen Vortrag.
Heute an einem Meeting teilgenommen, bei dem offensichtlich kein Gedanke an das Publikum verschwendet wurde. Genauso hat es sich angefühlt: ohne roten Faden, ein Sammelsurium an Details. Bin frustriert raus.
Heute den Renovatebot und einen Teil der Automatisierung der Wartung kennengelernt, die dadurch abgenommen werden kann. Cool.
Terraform als IaC Tool ist beliebt, allerdings Pulumi hat auch Potential.
In Meetings braucht es Mittel zur Fokusierung und Ergebnissicherung, sonst dreht sich alles im Kreis.
Es hilft Ergebnisse zu kommunizieren, wenn Aufgaben nicht zu generisch sind und auch den aktuellen Stand abbilden. Somit ist auch ein Fokuswechsel möglich, auch wenn nicht wünschenswert.
In einem Gespräch wurde klar, dass der Kunde so stark in das operative Arbeit drängt, dass es sich wie Mikromanagement anfühlt.
Ich hatte erst Konstanten für die subnet ids im Code. Wurde daraufhin gewiesen, das vpc und die zugehörigen subnet ids abzurufen. Klappt wunderbar.
Der Abschied eines Teammitgliedes ist immer etwas schmerzhaft. Allerdings enden damit auch Konflikte die sehr stark aus der Persönlichkeit des Mitgliedes getrieben wurden. Das ist auf der einen Seite unbefriedigend, weil ungelöst und damit unfertig, auf der anderen Seite aber auch befreiend, weil sie einfach "aufhören".
Lambda Funktionen können nicht konfiguriert werden, gewisse Loggroups zu benutzen, sondern
sie loggen (wenn sie dürfen) nach /aws/lambda/<functionName>.
Die Verbindung zwischen sns topics und lambda ist eine subscription. War mir neu.
Bei einem Workshop zu "Gewaltfreier Kommunikation" habe ich in einer Paarübung gelernt, dass ich schlecht Bedürfnisse benennen kann. Mir fehlt teilweise Wortschatz um Bedürfnisse eigene, wie auch die anderer auszudrücken.
Als Gruppe haben wir das Ziel und den Rahmen eines Vorhabens ausdiskutiert. Obwohl es nach einer Stunde zu kippen drohte, weil einer der Teilnehmer ungeduldig wurden, haben wir weiter gemacht. Zum Ende sagte genau dieser Teilnehmer: "Jetzt verstehe ich auch warum es vorhin unklar war.". Es hat sich gelohnt.
Es bestand der Verdacht, dass git squash merges unbeabsichtigt Änderungen überschreiben. Nach zwei Stunden Fehlersuche, war ich mir sicher, dass ein Merge eines alten Branches Ursache war.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent