Hardware-RAIDs
5
-
Einträge
32 -
Kommentare
106 -
Aufrufe
32.508
Mitwirkende
-
8
-
8
-
4
-
3
-
.thumb.png.fbbbcad646797acd9747cf9b465b0d40.png)
3
-
2
-
1
-
1
-
1
-
1
Über diesen Blog
Du* möchtest hier mitbloggen? --> Info & Kontakt - Schickt uns gerne Eure Gastbeiträge**
* Mach mit, wenn du über IT-Themen schreiben möchtest | ** kein Anspruch auf Veröffentlichung
Einträge in diesem Blog
Usability und du - Ein Seminarbericht und eine Übersicht über UI/UX
Daraus ergibt sich, wenn man genau ist, nicht die Anforderung
"Der Benutzer muss am System an einem Drehregler einen Wert von 0-5 einstellen können", sondern eher etwas wie "Der Benutzer muss am System die gewünschte Zieltemperatur eingeben können." Was passiert, wenn man so eine Anforderung konsequent zu einem sogenannten "interaktiven System" weiterentwickelt, sieht man beispielhaft hier. Das System ist bezüglich der Temperaturmessung im Raum zwar noch nicht zu 100% ausgereift, aber ein gefühlter Quantensprung an "Mehrkontrolle" gegenüber einem regulären Heizungsventil. Denn sind wir mal ehrlich, wer kennt die Situationen nicht, in denen man wie ein Verrückter zwischen "2.5" und "4.5" am Heizungsventil hin- und herdreht. Noch spannender wird es, wenn man den Nutzungskontext einer "Heizung" genauer analysiert. Dann stellt man schnell fest, dass es nicht darum geht, eine "Zieltemperatur einzustellen", sondern dass es "angenehm temperiert ist". Analysiert man diesen Gedanken weiter, könnte es z.B. mit einem "Wearable Computer" verbinden um anhand der Körpertemperatur und der Entfernung zum Haus die Heizung so anzuschalten, dass die Wunschtemperatur immer automatisch gehalten wird. Fahre ich also weg, fährt die Heizung so weit herunter, dass sie, wenn ich jetzt umdrehen würde, bei der Ankunft zu Hause wieder auf der "Wohlfühltemperatur" steht. Boom! Innovation. Etwas, das als neu oder mit "Wow"-Effekt wahrgenommen wird, weil es bestehende Prozesse drastisch vereinfacht, verbessert oder einfach völlig anders löst als bisher bekannt. Das Seminar - "Usability in a nutshell" Angefixt von dem Talk auf der Konferenz haben mein Kollege und ich uns also ein gutes halbes Jahr später im Mietwagen nach Richtung Köln auf den Weg gemacht. Dadurch, dass der Talk auf der Konferenz so gut war, haben wir uns auch direkt dazu entschieden, das Training ebenfalls bei Herrn Geis von der Firma ProContext durchzuführen. Bevor jemand fragt, ich kassiere hier keine Provision, ich bin einfach wirklich begeistert von den Inhalten und der Art der Vermittlung. "Human centered design process" Nach dem Check-In im B&B-Hotel Köln/Messe und einem sehr geschmeidigen Abendessen in einem mexikanischen Restaurant ging es am nächsten Morgen ausgeschlafen und frisch gestärkt mit dem Zug Richtung Innenstadt zum Konferenzhotel direkt am Kölner Dom. Tag 1 - Usability-Basics Bevor in tatsächliche Übungen eingestiegen werden konnte, gab es erstmal eine ordentliche Portion Theorie. Denn bei der Herstellung gebrauchstauglicher Produkte gibt es eine Menge Dinge, die einem begegnen können, die sehr präzise eingeordnet werden müssen, um sie richtig zu deuten. Die ISO-9241 und die Seminarinhalte vermitteln uns genau diese Sprache, diese Begriffe mit denen es möglich ist, solche Themen und diffusen Konzepte konkret zu benennen und damit zu arbeiten. Programmübersicht Tag 1 Themen waren unter anderem "Erfordernisse", "Anforderungen" und was deren Unterschied ist. Ein Erfordernis z.B. ist oft unbewusst, ein sogenanntes "implied need" und muss systematisch im Nutzungskontext erhoben werden. Eine Anforderung wiederum befriedigt bei Erfüllung ein Erfordernis und basiert auf diesem. An 2 Beispielen möchte ich das kurz exemplarisch für andere erläuterte Begriffe darlegen. Alles ausführen kann und möchte ich hier nicht, das würde a) den Rahmen sprengen und müsste ich euch das vermutlich beim Lesen in Rechnung stellen. Erfordernis Syntax: Die <Benutzergruppe>, muss XXX wissen / verfügbar haben, um YYY entscheiden / tun zu können. Es gibt also immer eine Voraussetzung und einen Zweck, die im Erfordernis festgehalten sind, welches wiederum im Nutzungskontext verankert sein muss. Ein Beispiel für eine Vorrichtung zum Garen von Eiern: Anforderung Syntax: Der Benutzer muss am System ZZZ erkennen/überblicken können auswählen können eingeben können Daraus ergäbe sich für unsere Garvorrichtung folgende beispielhafte Anforderung: Wie diese Anforderung jetzt technisch umgesetzt wird, ist an dieser Stelle bewusst offen gehalten. Ob eine grafische Anzeige, eine Push-Mitteilung auf das Smartphone (IoT ist ja in aller Munde momentan), eine Melodie oder was auch immer das "Beste" ist, wird im Anschluss im Test überprüft. Des weiteren wurden die 7 Dialogprinzipien und ihren Auswirkungen auf die Gestaltung von Nutzungsschnittstellen thematisiert. Am Ende des ersten Workshop-Tages wurden gemeinsam in Übungen aus Nutzungskontextbeschreibungen Erfordernisse und aufbauend darauf Anforderungen her- bzw. abgeleitet. Interviews und Nutzerbeobachtungen spielen dabei im Vorfeld eine entscheidende Rolle. Der Tag war also schon gefüllt mit ordentlich Inhalt, sowohl qualitativ als auch quantitativ. Und es zeichnete sich nicht ab, dass das weniger werden sollte. Im Gegenteil. Um die Inhalte gebührend zu verarbeiten und Platz für Neues zu machen, gönnten wir uns mit einem Teil der Truppe nach einem Besuch des Weihnachtsmarktes am Kölner Dom gemeinsam im "Früh am Dom" noch das ein oder andere Kölsch. Tag 2 - Entwickeln und Testen von UI/UX-Lösungen Noch leicht schwammig im Kopf vom Kölsch ging es mit der Bahn zurück zum Hauptbahnhof und von da aus ins Schulungshotel. Wenn Tag 1 den Fokus darauf legte, die Basis zu legen und Erfordernisse und Anforderungen zu sammeln, war der Hauptinhalt von Tag 2, zu erkunden, wie man dieses Wissen jetzt in ein Produkt, oder besser, einen Prototypen bzw. eine evaluierbare Geschäftsidee überführt. Der oben schon verlinkte "Menschzentrierte Prozess zur Gestaltung gebrauchstauglicher interaktiver Systeme" war die Basis, auf der der zweite Tag basierte. Nachdem man Erfordernisse identifiziert und Anforderungen hergeleitet hat, ist der nächste Schritt im Prozess, eine Designlösung zur Evaluierung zu erarbeiten. Auf gut deutsch: "Einen Prototypen zum Testen bauen." Dafür gibt es natürlich verschiedene Dinge, die man beachten muss. Ein paar Begriffe, Konzepte und Informationen, die dazu gehören, will ich hier exemplarisch auflisten. Kippschalter - Benutzung offensichtlich Affordance -Aufforderungscharakter Der Grad der Affordance beschreibt, wie sehr ein Element in einer Nutzungsschnittstelle zu seinem korrekten Gebrauch auffordert. Einem Schalter ist z.B. recht deutlich anzusehen, dass man ihn umlegen kann. Ich habe allerdings auch schon Dimmschalter gesehen, die man zum Anschalten nach unten "streicheln" musste und zum Abschalten bzw. dimmen nach oben. Aus Usability-Sicht ein ziemlicher Griff ins Klo. Intuitiv Im Usability-Sprech spricht man von Intuitivität, wenn die Benutzung eines interaktiven Systems unabhängig von der Erfahrung, vom Wissen, von den Sprachkenntnissen und dem momentanten Konzentrationsgrad des Benutzers unmittelbar verständlich ist. Das heißt in der Praxis, dass ein Geldautomat dann intuitiv ist, wenn man ihn am Ballermann als 16-Jähriger, der zum zweiten mal in seinem Leben Geld abhebt, grade bierbedingt 2,5 Promille intus hat trotzdem bedienen kann. Obwohl der Automat grade in "Spanisch" eingestellt ist. Leichter gesagt als getan also. Mentales Modell Unter einem "Mentalen Modell" versteht man die Vorstellung, die ein Mensch von der Umgebung, den Menschen und Dingen hat, mit denen er interagiert. Wasserhahn mit klassischer "blau - kalt, rot - warm"-Färbung Das Mentale Modell von einem Wasserhahn ist bei den meisten Menschen so konzipiert, dass es einen Griff zum Starten des Wasserflusses und einen Schieberegler zum Einstellen der Temperatur gibt. Das wäre das "Systemmodell". Ein Mensch, der zum ersten mal einen Wasserhahn mit Berührungssensor benutzen möchte, wird vermutlich Probleme damit haben, wenn er bis dahin noch keinen Kontakt zu dieser Technik hatte. Ein paar Jahre vorher gab es z.B. noch nicht mal den stufenloser Schieberegler am Mischer. So musste man noch manuell heißes bzw. kaltes Wasser aufdrehen, bis man die gewünschte Zieltemperatur erreicht hat. Moderne Systeme bieten hier (zumindest in der Dusche) oft schon eine auf den Regelmechanismus geätzte Temperaturskala an, die die Benutzung erleichtert. Wichtig ist für das mentale Modell jedoch diese Aussage. Joel Spolsky, Gründer von Trello und Mitgründer von Stack Exchange, hat dazu vor 17 Jahren(!) einen Blogpost geschrieben, der immer noch Relevanz hat. Neben diesen Konzepten wurde den "7 Dialogprinzipien" an diesem Tag erneut verstärkt Zeit gewidmet. Dazu habe ich in meinem letzten Blogbeitrag aber schon ausführlich etwas geschrieben. Ein weiteres Thema waren verschiedene Gestaltungsrichtlinien, sogenannte "Styleguides" oder "Design Patterns". Hierbei handelt es sich um Vorgaben, wie z.B. ein Button, eine Tabelle oder der gesamte Checkout Vorgang in einer Webseite (das wäre ein Design Pattern) aussehen sollte. Die meisten großen Hersteller von Software bieten so etwas übrigens an. Auf der Homepage unseres Trainingsanbieters findet ihr dazu einer super Übersicht. Nach einer kurzen Exkursion zur Gestaltung verschiedener Prototypen (z.B. Papierskizze, Storyboard, Wireframe, etc.) ging es zum Ende hin dann zum großen Thema "Evaluierung der Designlösungen", also dem Test der Prototypen. Diesem Kapitel, das unter anderem Fokusgruppen, Benutzerbefragungen und Usability Tests beinhaltet, werde ich mich aber aufgrund des Umfangs in einem gesonderten Blogbeitrag widmen. Wir schlossen den Tag mit einer Übersicht über die verschiedenen Rollen im Usability Engineering Prozess, ein paar Übungsaufgaben und einem prall gefüllten Kopf für den morgigen Prüfungstag. Tag 3 - Prüfung zur Zertifizierung zum "UXQB® Certified Professional for Usability and User Experience – Foundation Level (CPUX-F)" Den Vormittag und den ersten Teil des Nachmittags wendeten wir am Mittwoch zur Aufarbeitung der Inhalte zum Überprüfen der Gestaltungslösungen (also Usability Testing und co.) auf. Am Nachmittag wurde es dann spannend. Die Prüfung stand an. Dazu folgende Rahmenbedingungen. 40 Fragen Zum Bestehen müssen 28 von 40 Punkten erreicht werden (70%) 75 Minuten Keine Hilfsmittel erlaubt Jede Frage hat 6 Antwortmöglichkeiten, bei denen eine "signifikant richtiger" ist als die anderen Gibt es nur eine richtige Antwort, gibt es einen Punkt für eine richtige und null Punkte für eine falsche Antwort Manche Fragen haben 2 oder 3 "signifikant richtigere" Antworten, wenn dies der Fall ist, geht es aber aus der Aufgabe deutlich hervor Gibt es mehrere richtige Antwortmöglichkeiten, gibt es für jede richtige Antwort 1/AnzahlMöglichkeiten Punkte. Für jede falsche Antwort gibt es 1/AnzahlMöglichkeiten Punkte Abzug. Die Gesamtpunktzahl kann aber nie negativ sein. Die Fragen wurden, soweit ich das beurteilen kann allesamt durch die Übungen und Beispiele im Training im Vorfeld abgedeckt. So habe ich es dann auch geschafft, stolze 87,50% zu erreichen. Die Schwierigkeit der Fragen war allerdings stark gemischt. So gab es von relativ einfachen Fragen wie "Bei welchen der folgenden Begriffe handelt es sich um Dialogprinzipien?", wo die Lösung einfach aufgrund der Namen recht simpel war bis hin zu sehr schwierigen Fragen, wo mehrere Lösungen tatsächlich richtig waren, aber eine eben ein "Stückchen richtiger" als die anderen eine große Durchmischung. Da ging es z.B. um eine Fehlermeldung in Form eines Fehlercodes nach einer Datumseingabe in einer Webseite und einen Vorschlag zur Verbesserung. Gegeben waren von der ausführlicheren Fehlermeldung hin zum "Tutorial" verschiedene Möglichkeiten. Die richtige war jedoch, die Datumseingabe durch eine Datumsauswahl zu ersetzen, um Tippfehler, die erst validiert werden müssen überflüssig zu machen. So einfach kann's gehen. Alles in allem machbar, aber knackig. Fazit Meiner Meinung nach waren das drei sehr gelungene Tage und wohl investiertes Geld. Geld heißt hier 1.500€ zzgl. MwSt. für das Training und 300€ zzgl. MwSt. für die Prüfung. Eine Rückerstattung bei Nicht Bestehen gibt es hier selbstverständlich nicht. Obwohl die Möglichkeit besteht, sich extern auf die Prüfung vorzubereiten und die Unterlagen dafür im Internet frei verfügbar sind, halte ich ein vorbereitendes Training für sehr wertvoll, um das Wissen im Kontext richtig einordnen zu können. Darüberhinaus hat man durch den Kontakt mit anderen Teilnehmern die Möglichkeit, sich über Praxiswissen und echte Anwendungsfälle direkt austauschen zu können, was in der Gruppe sehr wichtig war. Ich gucke heute noch regelmäßig in meine Schulungsmappe und das im Training bzw. für die Prüfung erworbene Seminar hilft mir tatsächlich, im Alltag bessere Entscheidungen zu treffen, wenn es um Produkt- oder Prozessgestaltung geht. Und da ist egal, ob es sich um digitale Produkte handelt oder "welche zum Anfassen". Wenn ihr Fragen habt, zögert nicht, hier zu kommentieren oder mir zu schreiben. Gruß, euer "devopsdad" Patrick
Praktikumssuche während der Umschulung - Teil 2
Praktikumssuche während der Umschulung - Teil 1
Die 7 Dialogprinzipen
Powershell - Teil 2
Dokumentation/Kommentierung
Bei mir hat sich bewährt, dass ich am Anfang eines Skriptes erst einmal als Kommentar das Ziel des Skriptes definiere. Dieser kann sich ja immer wieder verändern, aber später spart man sich auch diese Arbeit, wenn man das Skript einmal in andere Hände geben möchte, denn dann gehört so ein Text einfach dazu. Wenn ihr Funktionen schreibt, dann sollten folgende Punkte aufgeführt sein: SYNOPSIS Hier sollte in 1-2 Sätzen die Bestimmung der Funktion stehen DESCRIPTION Eine ausführlichere Beschreibung was diese Funktion macht PARAMETER param1 Beschreibung des param1 PARAMETER param2 Beschreibung des param2 Notes Zusätzliche Notizen LINK Zugehörige URLs Die erste URL wird aufgerufen wenn das CDMlet Get-Help -Online <Funktionsname> aufgerufen wird INPUTS Typen der Datenübergabe die erlaubt sind OUTPUTS Typen der Datenausgabe die von dieser Funktion ausgegeben werden können Funktionen benennen Bei der Wahl des Funktionsnamens sollte man sich an die offizielle Nomenklatur halten. Das bedeutet, dass der Name mit einem Verb und einem Substantiv durch ein "-" getrennt aufgebaut sein sollte. Get-Verb gibt euch eine offizielle Liste der Verben und in welchem Kontext diese stehen. Wenn ihr allerdings eine Funktion nur für euch schreibt die nur lokal eingesetzt wird, schreibt vor den Funktionsnamen "private:" oder „script:“ Versionierung Beim Versionieren habe ich früher bei größeren Änderungen einfach den Versionszähler hochgesetzt und nebenbei eine Liste der Änderungen in einem Onenote Dokument gepflegt. Ihr könnt natürlich auch die Änderungen in einem Textdokument oder direkt im Skript kommentieren. Auch hier bieten die ISESteroids wieder eine sehr komfortable Lösung des Versionierens. Der Pfeil im Bild zeigt euch, wie ihr den Reiter der Versionierung aufrufen könnt. Auf der rechten Seite seht ihr Die File Version History. Links ein Button „Ad New Version“ und auf der rechten Seite eine Checkbox „Auto Mode“. Wenn bei Auto Mode der Haken gesetzt ist, wird automatisch eine neue Version angelegt sobald man Änderungen durchgeführt hat und darauf folgend speichert. In dem Reiter der einzelnen Versionen seht ihr links eine Klassifikationsmöglichkeit, wie zum Beispiel Stable, Alpha Release und weitere. Über den Knopf Compare öffnet sich das Programm WinMerge und zeigt die Veränderungen zur Vorgängerversion. Hier nutze ich den Button Notes um, wie der Name schon sagt, mir Notizen zu den Versionsunterschieden zu kommentieren. Falls ihr noch Anregungen, Fragen oder Hinweise habt, gerne her damit.
Powershell - Allgemeines
Kurze Vorstellung + Ausblick V-Blog
Die Windows Registry
Mathematische Grundlagen der Wirtschaftsinformatik
Eure Themenwünsche für Blog-Beiträge oder Podcast-Episoden
Stefan
Das ISO/OSI-Modell (Teil 4: Sitzungs-, Darstellungs- und Anwendungsschicht) - Fachinformatiker-Podcast #7
Das ISO/OSI-Modell (Teil 3: Transportschicht, TCP/UDP) - Fachinformatiker-Podcast #5
Das ISO/OSI-Modell (Teil 2) - Fachinformatiker-Podcast #5
Das ISO/OSI-Modell (Teil 1) - Fachinformatiker-Podcast #4
Management Basics
Berufsbegleitendes Studium
Vorstellung SebastianB.
Tipps zum Einstieg in die Ausbildung - Fachinformatiker-Podcast #3
Stefan PS: Ich habe einen RSS-Feed für diesen Podcast eingerichtet, damit du dir die Episoden auch direkt im Podcatcher deiner Wahl anhören kannst: http://fiae.link/FIPodcastRSS
Vorbereitung auf Projektpräsentation und Fachgespräch - Fachinformatiker-Podcast #2
Stefan PS: Noch mehr Tipps zur konkreten Gestaltung der Projektpräsentation gibt es in der aktuellen Episode des Anwendungsentwickler-Podcasts: Ansprechende Gestaltung der Projektpräsentation.
Slack – Mehr als nur ein Messenger
Und wenn man möchte, guckt man einfach in den Commit-Details nach.
Kleiner Wermutstropfen: Slack gibt es bisher nicht on Premise. Wer also etwas Vergleichbares intern aufsetzen will, muss wohl auf HipChat oder ähnliches ausweichen. Automatische Channelupdates per Trello-Integration #2: Ein agiles Team hat sich ein SmartBoard angeschafft und nutzt ein Trello-Board zur Verwaltung ihrer Tasks. Leider sitzen nicht alle Teammitglieder in einem Raum. Durch die Trello-Integration mit Slack werden Aktivitäten der Tasks auf dem Board automatisch in einen Slack-Channel mit übertragen. Teammitglieder können sich so auch außerhalb der Daily Stand-Ups einen Überblick über die Tätigkeiten verschaffen. Guckt einfach mal rein. Für die meisten Dienste und Apps, die ich kenne, gibt es bereits eine Unterstützung in irgend einer Form in Slack. Was kostet das? Gar nichts. Also in der Basisversion. Und die reicht zum Evaluieren oder für kleine bis mittelgroße Teams definitiv aus.
Für alles darüber gibt es in der Preisübersicht einen guten Überblick über die Kosten.
Besonders schön: Die "Einarbeitung" in das Tool benötigt nicht mal sonderlich viel Zeit. Jeder, der schon mal irgendwie in einer WhatsApp-Gruppe war, wird sich mit den Grundfunktionalitäten von Slack in Browser und App schnell vertraut machen. Alte IRC-Nerds sogar noch besser. Fazit – TL;DR Slack ist ein leichtgewichtiges, aber mächtiges Tool, das es dem Benutzer ermöglicht, sich mit anderen Nutzern auszutauschen. Dokumente, Statusupdates, Informationen, alles voll durchsuchbar und indiziert. Wer sich davon nicht abschrecken lässt, dass es "in der Cloud" läuft, sollte Slack definitiv mal ausprobieren. Der potentielle Mehrwert, grade für räumlich getrennte Teams ist nicht zu unterschätzen. Euer "devopsdad" Patrick
Erfahrungsbericht 25. intrinsify.me wevent in Berlin
Das Unternehmen mahnt seinen Mitarbeiter ab, schickt dann aber als Versöhnungsmaßnahme die ganze Abteilung im Anschluss verpflichtend in den Kletterwald, um Vertrauen untereinander zu schaffen.
Der Mitarbeiter begibt sich aktiv auf Jobsuche. Fall 2: Das Team im Startup "DataNerds from outer space" hat die gleiche Situation wie die Firma BuzzwordSoft. Nur gehen sie damit anders um.
Sie erkennen, dass zwar letztendlich der Mitarbeiter den "Bock geschossen hat", in einem klärenden Gespräch unter Kollegen kommt jedoch heraus, dass dieser privat momentan viel Stress hat und der direkte Kundendruck das Fass zum Überlaufen brachte. Er wollte das Problem einfach schnell beheben; leider war er damit nicht erfolgreich.
Das Team stellt fest, dass der einzelne zwar "den Fehler" begangen hat, dieser jedoch mit einem Prozess aus Unit Tests, Integrationstests, einer automatisierten Build Pipeline und 4(oder mehr)-Augen-Reviews gar nicht erst passiert wäre, unabhängig von der privaten Situation des Kollegen. Statt den Kollegen zu vergraulen beschwichtigt man den Kunden und beginnt, das Produkt robuster zu designen und eine automatisierte Buildpipeline mit frei verfügbaren Open Source Tools zu erstellen.
Der Mitarbeiter fühlt sich als Mensch wahrgenommen und geht trotz des Vorfalls gern zur Arbeit. Anfahrt nach Berlin. Autobahn A2. Hagel. Gewitter. Die Frisur hält. Natürlich sind die beiden Beispiele stark überzeichnet. Jedoch dienen sie meiner Meinung nach gut der Veranschaulichung, wie unterschiedlich man je nach Kontext, Systemumgebung und Sozialisierung mit Problemen umgehen kann. Solche und ähnliche Fragestellungen werden oft von den Mitgliedern des Netzwerks beleuchtet. Der Hintergrund hier ist, dass wir in unserer modernen, von Dynamik geprägten Arbeitswelt mit den Methoden klassischen Managements oft nicht mehr weiterkommen.
Und damit man sich dazu nicht nur im Internet oder auf den sogenannten "intrisify.meetups"(eine Art Stammtisch, ähnlich wie User Group-Treffen) austauscht, gibt es mittlerweile im 2-Monats-Turnus die sogenannten "Wevents", auf denen man mit dem Rahmen "Open Space" diskutieren, Lösungen erarbeiten und sich mit seinen unterschiedlichen Hintergründen und Fragen begegnen kann. "Ich will nicht nach Berlin♪♫" - Das Wevent Ein paar Entscheidungen zur Planung und Finanzierung, eine Buchung per AirBnb, eine gepackte Reisetasche und 5 Stunden Autofahrt durch Gewitter und Hagel später waren mein Kollege und ich dann endlich in Berlin angekommen. Freitag Abend gab es ein Warm-Up zum Kennenlernen im Wirtshaus Max und Moritz. Hier konnte man sich schon mal gegenseitig zu Speis und Trank beschnuppern und bekam einen kleinen Eindruck vorab, wie die Stimmung am Wochenende werden sollte(Spoiler: Verdammt gut). Sessionsammlung vom Samstag - Entscheiden, du dich musst! Samstag "früh" um 9:00 war dann Einlass in der Forum Factory, einer ziemlich coolen Location, die als Tagungs-, Seminar- oder Gallerieraum dienen kann. Nach einer kurzen Vorstellung der Open Space-"Grundsätze" ging es dann auch schon an die Sessionplanung. Jeder konnte Themen einbringen, die dann parallel in verschiedenen Räumen diskutiert werden konnten. Der Charakter der Session war jedem selbst vorbehalten. So gab es z.B. eine Session "Wieviel(sic!) Persönlichkeit braucht Future Leadership?", in der eine Diskussion im Fishbowl-Format der Kern war. Andere Sessions waren ein "einfacher" Erfahrungsaustausch im Gespräch, die Möglichkeiten zur Moderation und zum Austausch waren jedem selbst überlassen.
Neben dem eigentlichen Inhalt der Sessions hat mich am stärksten die Haltung der Teilnehmer im Gespräch beeindruckt. Es herrschte eine unfassbar große Offenheit, eine hohe Reflexionstiefe und ein sehr ehrlicher Umgang mit Kritik. Bei vielen Gesprächen war implizit eine Vertrauensebene vorhanden, auch mit persönlichen Themen "nach außen" zu gehen, weil einfach eine Wohlfühlstimmung und ein "Hier kann ich ich sein"-Gefühl im Raum standen. Vegane Leckereien, bereitgestellt vom "Supermarkt-Team" Samstag Abend gab es die Option, sich im Café brennBar zu Abendessen und weiterem informellen Austausch und Netzwerken zu versammeln, was auch von vielen wahrgenommen wurde. Ich selbst hatte viele Gespräche zum Thema "Beruf und Familie", die mich in meinem Selbstbild als Vater und Berufstätiger teils bestätigten, aber auch viele neue Impulse legten, über mein Handeln unter neuen Gesichtspunkten zu reflektieren. Sonntag gab es noch einmal die Möglichkeit, neue Sessions oder Folgeangebote vom Vortag anzubieten. Da man sich schon etwas besser kannte, ging es auch hier wieder ordentlich "in die Tiefe", und gefühlt waren die Gespräche noch eine Spur bedeutsamer und "impulsgebender"(gibt es das Wort?) als am Vortag. Zu dem Zeitpunkt machte sich in meinem Kopf aber schon das Gefühl breit, ob der Menge an Input nicht mehr so ganz auf der Höhe zu sein. Ich nutze eine Zwischenpause, um auf meinem Surface(das sich das Wochenende als treuer Begleiter erwiesen hat) die bisherigen Gedanken zu strukturieren und in Form zu bringen. Die Teilnehmer hatten die Möglichkeit, ihre Lieblingsbücher auszulegen... Eine weitere, aber prägnante Besonderheit im Gegensatz zu anderen Veranstaltungen dieser Art möchte ich noch erwähnen, da sie meiner Meinung nach viele Gedanken, die dieses Netzwerk antreiben, sehr gut wiederspiegelt. Nämlich die Bezahlung. ...und Heidewitzka, waren das viele gute Bücher. Im Eingangsbereich der Forum Factory liegen Excel-Listen aus, welche die Reinkosten des Wevents darstellen. An der Wand hängt dazu passend ein Flipchart, das anzeigt, wie viel die Veranstaltung insgesamt kostet und was bisher an Einnahmen erfolgt ist. Während der Veranstaltung wird dieser Stand ständig aktualisiert. Der Hintergrund ist hier, dass die Veranstaltung zum einen als selbsttragend angelegt ist(also keine Profitveranstaltung) und zum anderen, dass es keine festen Beiträge gibt. So waren am Wochenende 185€ als empfohlener Betrag angegeben. Wer mehr zahlen kann und möchte, darf das genauso tun, wie jemand, der das nicht kann oder mag. Und man mag es kaum glauben, das funktioniert. Fazit - TL;DR Was habe ich von dem Wochenende mitgenommen und was erhoffe ich mir von der Mitgliedschaft bei intrinsify.me(die übrigens kostenlos ist)? Ich habe viele unfassbar aufgeschlossene Menschen mit tollen Ideen und Gedanken getroffen. Ich habe ein Netzwerk kennengelernt, dass es zu schaffen scheint, dabei zu helfen, diesen Ideen Form zu verleihen und über den Status der "Spinnerei" hinauszuwachsen. Ich hatte ein geniales Wochenende in Berlin, obwohl ich von der Stadt außer dem Checkpoint Charlie beim Abholen unseres Autos nicht wirklich etwas gesehen habe. Und ich habe sehr viel über mich selbst gelernt. In meiner Position als Angestellter, als Vater und als Mensch überhaupt. Wenn ihr in eurer Nähe mal ein Wevent und dazu Interesse an dem Thema "Neue Arbeitswelt" habt, ich kann euch nur empfehlen, euch das ganze mal anzusehen. Gruß, euer "devopsdad" Patrick aka Goulasz
Buchvorstellung: Denkwerkzeuge der Höchstleister
Schlecht ist nur, darauf als Organisation nicht vorbereitet zu sein und dann nicht reagieren zu können. Denn dann steht man im Zweifel ohne Schirm und Jacke "im Regen". Aufbau Ein Hauptteil des Buches ist der Glossar, auf dem die präzisen Begriffe, die in diesem(sytemtheoretischen) Kontext genutzt werden, erläutert und eingeordnet werden. Dem voran gehen ein Vorab-Bereich in dem der Aufbau im Detail erläutert wird und 13 kurze, 10 Seiten nicht übersteigende Kapitel, die klassische Management-Thesen im Kontext moderner, dynamischer Märkte beleuchten. In diesen Kapiteln gibt es zusätzlich zu den im Fließtext sehr anschaulich formulierten Thesen und Vergleichen die sogenannten "Denkzettel". Diese beschreiben ein Problem und geben einen Hinweis, in welche Richtung man sich bewegen kann, um eine mögliche Lösung im eigenen Unternehmenskontext zu finden. Denkzettel "Zentrum und Peripherie" samt Kapitelresümee "Taylorismus - Aufstieg und Fall einer genialen Idee", Quelle: "Denkwerkzeuge der Höchstleister: Warum dynamikrobuste Unternehmen Marktdruck erzeugen" von Wohland/Wiemeyer, Unibuch Verlag Das klingt erstmal recht kompliziert, wenn man jedoch begriffen hat, dass man das Buch weder am Stück noch in der geschriebenen Reihenfolge lesen muss, sondern es immer und immer wieder als Nachschlagewerk und Referenz nutzen kann, passt dieses gut sortierte Format ganz hervorragend. Die Denkzettel sind ein großartiger Einstieg, um sich mit der Systemtheorie und den Denkwerkzeugen auseinanderzusetzen, wenn man in diesem Umfeld noch völlig unbedarft ist. Wer in die Tiefe gehen will, liest einfach die umspannenden Kapitel. Zielgruppe und Fazit Das Buch ist für alle geeignet, die das Gefühl haben, Projekte in ihrer Organisation laufen "irgendwie schlecht", verfehlen oft das Ziel, Kunden und Mitarbeiter sind unzufrieden, die Konkurrenz überholt uns ständig, Sarkasmus ist an des Tagesordnung, es gibt "zu viele Meetings"; aber keiner weiß so richtig wieso, etc. Das Buch ist definitiv nicht für Menschen geeignet, die sich eine schnelle Lösung per "Best Practice" erhoffen und der Meinung sind, man könnte per steuernder Direktive "von oben" Dinge wie Unternehmens- und Wertekultur der Mitarbeiter ändern oder steuern. Das dies nicht funktioniert, machen die Autoren immer wieder mit vielen Beispielen zum Thema "Kultur" und "Steuerung" im Unternehmen klar. Mir selbst hat das Buch viele Ansätze und Handlungsräume eröffnet, die mir helfen zu verstehen, wieso im Beruf so oft so viel "Theater" um Probleme gemacht wird, die eigentlich mit dem berühmt-berüchtigten "gesunden Menschenverstand" einfach zu beheben sein sollten.
Ich nutze es regelmäßig und gehe schon fast missionarartig damit hausieren, weil ich es schlicht und einfach großartig und unendlich wertvoll finde. Ganz akut Interessierten aus der Umgebung kann ich mein Exemplar zum Reinschnuppern gerne auch Ausleihen. Für alle anderen gibt es in der Linksektion noch mehr Futter. Viel Spaß beim Stöbern! Euer "devopsdad" Patrick aka Goulasz Weiterführende Links zum Thema Hier gibt es die Denkzettel im PDF-Format: Denkzettel bei dynamikrobust.com Hier der Link zum Buch bei Amazon: Denkwerkzeuge der Höchstleister Intrinsify.me-Netzwerk zum Thema "Moderne Unternehmensführung" und "Sinnkopplung im Job": Intrinsify.me Wikipedia-Artikel zur Systemtheorie zum Warmwerden und Einlesen: Systemtheorie
Konferenzreview: DevOpsCon 2015 in München
Nach dem Abendessen ging es mit den Kollegen eine Runde im Pool schwimmen, den grandiosen Ausblick auf den Liegen um den Pool genießen, den nächsten Tag planen und damit war der Abend meistens auch schon rum. Tag 1(Workshop) Zum geschmeidigen Start in den Montag gab es den "Docker-Basis-Workshop" von und mit Peter Roßbach, seines Zeichens Systemarchitekt, Docker-Experte der ersten Stunde und "DevOps"-Enthusiast. Selbst bis dato auf *nix-Systemen völlig unbedarfte Entwickler(wie mich) waren mit Peters Anleitung und aufgrund der Einfachheit der Docker-Syntax in der Lage, in Kürze Container für Webserver, Datenbankserver mit entsprechenden Befehlen zu erzeugen und die Netzwerke gleich mit zu konfigurieren. Mächtiges Tool und mächtige Architektur diese Container-Technologie. Mit einer verhältnismäßig niedrigen Hemmschwelle zum Einstieg und Unmengen an Blogs, Snippets und Infomaterial zu Docker selbst im Netz scheinen die Docker-Container in *nix-Umfeldern eine echte Bereicherung zu sein, wenn es darum geht, skalierbar schnell Infrastruktur bereitzustellen. Obwohl ich mit Infrastruktur und mit Linux bisher wenig zu tun hatte, das hat definitiv mein Interesse geweckt. Der Raspi liegt im Warenkorb. Bücher zu Docker übrigens nicht, die sind oft schon beim Erscheinen veraltet. Nicht vorenthalten möchte ich euch noch folgendes Zitat von Peter zur Frage , wie man diese Technologie in einer abgeschotteten, kontrollierten Konzern-IT-Infrastruktur implementieren könnte: ¯\_(ツ)_/¯ Tag 2&3(Konferenz, Expo) Nach einem überschaubaren ersten Tag gab es an den Tagen 2 und 3 ausschließlich Vorträge, Keynotes und informell gestaltete Treffen zum Austausch(Open Space-ig). Gemeinsam war allen von mir besuchten Vorträgen, das sie unglaublich viel Lust aufs "Basteln" machten. Was sich in der Praxis aufgrund der Open Source-Natur vieler genutzten Tools als gar nicht so schwierig herausstellen sollte. Am interessantesten waren für mich die Talks zum Thema Unternehmenskultur und Veränderung in der Organisationsstruktur des "DevOps"-Unternehmens. Besonders hervorstechend waren da für mich zum einen Wix.com(WYSIWYG-Baukasten für Webseiten) und zum anderen dm(Ja, die Drogerie). Bei Wix war sehr interessant, wie der Referent Aviran Mordo klar und einfach zeigte, dass man nicht jedes Tool benutzen muss, solange man nicht den "Schmerz spürt", den der Einsatz des Tools zu lindern vermag. Wenn deine Idee grundsätzlich Mist ist, bringen dir die besten Tools nichts, deine Idee bleibt Mist. Das Bild spricht denke ich für sich. dm im Kontrastprogramm merkte recht schnell, dass man als "Drogerie" mit offenen Augen und Ohren durchaus Gewinn mit ordentlichen Onlineportalen und Webshops machen kann. Ein Onlineshop, der schnell auf die Bedürfnisse der verschiedenen Kunden reagieren kann und in kurzen Abständen qualitativ hochwertige Stände online stellen kann war hier das Credo. Daraus folgte fast natürlich und logisch eine Umstellung des Deployment-Prozesses in Richtung Continuous Delivery und ein damit einhergehendes Umdenken in der Unternehmensorganisation.
Im Verlauf des Talks wurde klar, dass zum einen Vertrauen und Offenheit für ein solches Umdenken notwendig sind. Zum anderen auch, dass dafür nicht jeder bereit ist. Unterm Strich kam jedoch eine effizientere Organisation bei dem Prozess heraus. Fazit - TL;DR Das nicht immer alles eitel Sonnenschein ist, war bei allen Vorstellungen von Tools oder Prozessen, die durchlebt wurden, immer zu erkennen. DevOps an sich bedeutet in erster Linie, Verantwortung gemeinsam zu übernehmen für ein geteiltes Bild eines Produkts oder eines Prozesses. Was oft vergessen wird, ist aber, dass dieses Bild manchmal gar nicht existiert oder abteilungsübergreifend völlig anders wahrgenommen wird. Empathie, echtes Verständnis füreinander und für die Anforderungen des Gesprächspartners waren immer wiederkehrende Merkmale, die notwendig sind, damit so etwas wie Continuous Delivery funktionieren kann. Tools, Tools, Tools! Zum Abschluss noch ein paar Links und Einzeiler zu vorgestellten Tools, falls jemand bastelwütig wird: Docker - Software, mit der man andere Software(z.B. Betriebssysteme, Webserver, Datenbankserver,...) virtualisiert in "Containern" verpacken kann, die dann auf jedem System funktionieren Hadoop - Framework für verteilte Software. Man nehme 10 Raspis, schalte sie zusammen und e voilá: Man hat einen Hadoop-Cluster-Datenbankserver ELK-Stack - Bestehend aus Elasticsearch, Logstash und Kibana zum Durchsuchen, Ablegen und Visualisieren von Logs aller Art OWASP ZAP - Zum manuellen oder automatisierten Security-Scan(aktiv, passiv) von Webanwendungen, auch automatisiert in Jenkins verwendbar Jenkins - Tool für Continuous Integration und so ziemlich alles, was dazu gehört. Lächerlich viele und gute Plugins verfügbar Consul - Service Discovery-Tool, das neue Dienste, die verfügbar werden, automatisch erfasst und diese verwalten kann. Nützlich aber erst, wenn man schon mehrere Microservices im Einsatz hat, sonst tut es auch ein DNS-Eintrag Github - Viel mehr als nur das, aber hauptsächlich ein Repository-Server für GIT Euer "devopsdad" Patrick aka Goulasz
Häufige Fragen im Forum - Fachinformatiker-Podcast #1
Stefan PS: Auf eine Vorstellung meiner Person habe ich an dieser Stelle verzichtet. Ich bin Stefan! Wenn dich im Detail interessiert, wer hier schreibt und spricht, schau einfach auf meiner Website vorbei: Über mich.
-
-
Blogkommentare
-
Von Tician · Geschrieben
1. Bild ist raus. Zum Rest: Empfinde ich als nicht wichtig genug für einen Blog der die Grundlagen vermitteln soll. -
Von Chief Wiggum · Geschrieben
Erstens: Copyright ist dir unbekannt? Auch für einen Blogbeitrag darf man nicht einfach ein Bild aus dem Internet verwenden. Zweitens: der von dir verlinkte Controller dürfte nicht viel schneller sein als ein Software-Raid. Mehr dazu unter Punkt 4. Drittens: Ein echtes Hardware Raid gewinnt seine Leistung unter anderem auch dadurch, dass der Controller einen eigenen Cache besitzt. Warum schreibst du nichts darüber? Was ist mit einem BBU und warum sollte dieses Bauteil zwingend bei einem Raid dabei sein? Viertens: der von dir im Bild gezeigte Controller ist ein einfacher SATA-Controller aus alten Tagen (es ist ein PCI-X Controller, das war mal state of the art als ich zum ersten Mal intensiver mit IT in Verbindung kam), der ein RAID nur über die Treiber für die Karte erstellen kann, es also effektiv ein Controller für ein SOFTWARE-RAID ist. Siehe hier: https://www.semiconductorstore.com/cart/pc/viewPrd.asp?idproduct=42868 -
Von _n4p_ · Geschrieben
Ich kann die Infos nochmal raussuchen aber eigentlich ist es klar. bei RAID 6 werden 2 verschiedene Prüfsummen gebildet P und Q die auf die Platten verteilt werden. Unabhängig davon ob Q nun komplexer zu ermitteln ist als P braucht das mehr Rechenzeit. Das passiert zwar aufm Controller aber der kann auch nur n Operationen pro Sekunde. ob es belastbare Benchmarks gibt weiß ich nicht. Das gleiche gilt in ähnlicher Form fürs Rebuild und damit auch für den Betrieb im "degraded" Zustand. Je mehr Festplatten um so mehr Operationen pro Prüfsumme müssen durchgeführt werden. Auch ein XOR braucht Zeit, auch wenn es wenig ist. -
Von Tician · Geschrieben
1. Danke, ich habe eine Zeile hinzugefügt die darauf hinweist das es noch mehr RAIDs gibt. 2. Ich hab ein wenig gesucht, aber zu dieser Aussage konnte ich leider auf die Schnelle keine Informationen finden, könntest du mir sagen wo du diese Info her hast? 3. Das die Performance während eines Ausfalls sinkt hatte ich unter RAID 5 erwähnt. Unter RAID 0 ist auch nochmal erwähnt dass bei mehr Festplatten die Ausfallrate höher ist. Beides könnte man natürlich in einen allgemeineren Bereich nehmen, das ist wahr. Was mehrere Platten in RAID 5/6 betrifft und das bei mehr Platten die Zeit für den Rebuild steigt konnte ich leider auch nicht verifizieren - nur das die Zeit mit der Größe der Platte logischerweise steigt (1TB hat eine kürzere Rebuild-Zeit als eine 2TB-Platte). -
Von _n4p_ · Geschrieben
Mir fehlen hier noch typische Einsatzgebiete der jeweiligen RAID-Level, ein Verweis auf exotischere RAIDs. Es klingt auch ein wenig so als wäre RAID 6 ne total tolle Idee, allerdings erkauft man die Datensicherheit mit Performanceeinbußen gegenüber anderen Varianten. Es ist auch keine gute Idee viele Festplatten in ein RAID 5 oder 6 zu stopfen. Zum einen steigt die Wahrscheinlichkeit das mehrere Festplatten ausfallen und zum anderen steigt die Zeit für den Rebuild und die Performance sinkt während des Ausfalls.
-
Schicken Sie uns eine Nachricht!
