Um Scrum, eines der bekanntesten agilen Vorgehensmodelle, geht es in der einhundertzweiundsechzigsten Episode des IT-Berufe-Podcasts.

Inhalt

Scrum ist einer der bekanntesten und praxiserprobten agilen Entwicklungsprozesse. Die Bezeichnung "Scrum" (deutsch: Gedränge) kommt aus dem Rugby und bezeichnet das Aufeinandertreffen verschiedener Spieler "auf einem Haufen".

Entwickelt wurde Scrum von Ken Schwaber und Jeff Sutherland für die Softwareentwicklung, aber Scrum wird heute in allen möglichen Bereichen eingesetzt.

Scrum ist lediglich ein Framework und definiert z.B. keine konkreten Methoden für die Softwareentwicklung, wie es z.B. bei Extreme Programming der Fall ist (dort gibt es z.B. TDD, Refactoring, 40-Hour-Workweek etc.). Stattdessen verlässt sich Scrum auf selbstorganisierende Teams.

Scrum ist ein agiler, iterativer und inkrementeller Prozess, was bedeutet, dass er sich an die Gegebenheiten in konkreten Projekten anpassen lässt, in mehreren gleich ablaufenden Iterationen zum Ziel gelangt und dieses mit wachsendem Funktionsumfang erstellt wird.

Grundsätzlicher Ablauf von Scrum

Zunächst werden alle bekannten Anforderungen erfasst und geschätzt.

Dann werden die Anforderungen für die nächste Iteration identifiziert (z.B. wichtigste, kritischste, einfachste) und geplant.

Die Iteration ist time boxed. Sie wird nicht unterbrochen und auch nicht verlängert. Die Iteration heißt auch Sprint. Er ist üblicherweise 30 Tage lang.

Am Ende der Iteration steht dem Kunden ein "fertiges" Produkt zur Verfügung, das er sich anschauen und zu dem er Feedback geben kann.

Der Fortschritt der Arbeit wird täglich in einem kurzen Meeting im gesamten Team besprochen.

Die wichtigste Zahl bei Scrum ist die Drei: Es gibt jeweils drei Rollen, Artefakte und Meetings.

Rollen

Bei Scrum gibt es drei verschiedene Rollen: Team, Product Owner und Scrum Master.

Das Team führt die Arbeit aus und entscheidet wie viele Anforderungen es in einem Sprint umsetzen kann. Seine Arbeitsweise ist völlig frei durch das Team selbst bestimmbar, es gibt keine Vorgaben ("selbstorganisierendes Team").

Der Product Owner repräsentiert die Kundenbedürfnisse. Ihm "gehört" das Produkt und er trifft die nötigen Entscheidungen (in Abstimmung mit dem Kunden). Er entscheidet, welche Anforderungen für eine Version umgesetzt werden und wann die Software ausgeliefert wird. Er arbeitet eng mit dem Team zusammen und ist weit mehr als ein einfacher Produktmanager oder Projektleiter, hat aber keine Weisungsfunktion.

Der Scrum Master hilft allen Beteiligten, Scrum korrekt anzuwenden und unterstützt das Team, indem er z.B. "Impediments" (Hindernisse) beseitigt. Der Scrum Master ist kein Projektleiter, sondern sollte eher als "Consultant" oder "Coach" verstanden werden, der penibel prüft, ob die Regeln von Scrum eingehalten werden. Er hat daher auch keine Weisungsbefugnis.

Artefakte

Im Rahmen von Scrum werden drei verschiedene Artefakte erzeugt und bearbeitet: Das Product Backlog, die Sprint Backlogs und das (End-)Produkt. Die obige Darstellung zeigt die Zuordnung der einzelnen Artefakte zu den Phasen von Scrum.

Das Product Backlog ist das zentrale Instrument zum Erfassen und Managen von Anforderungen. Aus ihm werden die in den einzelnen Sprints umzusetzenden Aufgaben oder Tasks abgeleitet. Vereinfacht gesagt ist das Product Backlog eine absteigend nach Priorität sortierte Liste aller bereits geschätzten (!) Anforderungen an das Produkt.

Aus dem Poduct Backlog werden im Rahmen des Sprint Plannings die wichtigsten Anforderungen herausgenommen und für den nächsten Sprint in das Sprint Backlog übertragen. Dort werden alle nötigen Aktivitäten zum Erreichen des Sprint-Ziels aufgelistet und detailliert beschrieben. Das Team schwört sich auf das Sprint Backlog ein und verpflichtet sich zur Umsetzung der dort definierten Punkte ("commitment"). Das Sprint Backlog wird täglich aktualisiert.

Das Produkt(-inkrement) ist das wichtigste Artefakt,

Um das agile Manifest - die Grundlage aller agilen Vorgehensmodelle - geht es in der einhunderteinundsechzigsten Episode des IT-Berufe-Podcasts.

Inhalt

Das agile Manifest wurde 2001 von mehreren namhaften Softwareentwicklern aufgestellt als Gegenentwurf zum bisherigen Vorgehen bei der Softwareentwicklung.

Es bildet die Grundlage für alle agilen Projektmanagementmethoden und Softwareentwicklungsprozesse wie z.B. Scrum und Extreme Programming.

Das Manifest verbietet nicht die klassisches Vorgehensweise, zeigt aber bessere Alternativen auf, um zum gewünschten Ergebnis zu kommen.

Wasserfall und "klassische" Softwareentwicklung

BDUF: Big Design Up Front. Lange Planungsphase mit viel Dokumentation, danach "standardisierte" Entwicklung als "Abarbeitung" des Designs.

Umgang mit sich ändernden Anforderungen ist schwierig, weil das System zu starr ist, um darauf zu reagieren.

Durchschnittlich ändern sich aber 2% der Anforderungen an Projekte pro Monat.

Folge: Projekte verzögerten sich, wurden zu teuer oder lieferten nicht das gewünschte Ergebnis ("magisches Dreieck": Kosten, Zeit, Qualität).

Achtung: Wasserfall ist nicht immer schlecht. Es gibt auch Projekte, die sich gut dafür eignen (insb. das IHK-Abschlussprojekt).

Agiles Manifest

Siehe Manifesto for Agile Software Development.

We are uncovering better ways of developing

software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on

the right, we value the items on the left more.

Menschen sind wichtiger als Prozesse

Lauffähige Software ist wichtiger als Dokumentation

Zusammenarbeit ist wichtiger als Vertragsverhandlungen

Reaktion auf Änderungen ist wichtiger als das Verfolgen eines Plans

Einige Unterzeichner

Kent Beck: Begründer des Extreme Programming, Entwickler von JUnit, "Erfinder" von Test Driven Development (siehe Test Driven Development: By Example*)

Robert C. Martin: Autor von Clean Code*, Entwickler von FitNesse

Ward Cunningham: "Erfinder" des Wikis

Martin Fowler: Autor von Refactoring* und Patterns of Enterprise Application Architecture*

Ken Schwaber: "Erfinder" von Scrum

Literaturempfehlungen

Eine gute Einführung in agile Softwareentwicklung liefert das Buch Agile Softwareentwicklung* von Henning Wolf und Wolf-Gideon Bleek.

*

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Manifesto for Agile Software Development

Um reguläre Ausdrücke - das Schweizer Taschenmesser für ITler - geht es in der einhundertsechzigsten Episode des IT-Berufe-Podcasts.

Inhalt

Ich schwärme immer mal wieder von regulären Ausdrücken. Das liegt wohl einfach daran, dass ich fast täglich mit ihnen arbeite. Sie sind einfach so unglaublich vielseitig verwendbar und machen ITlern das Leben leichter - wenn man sie beherrscht. Nicht umsonst gibt es diesen "Witz":

Ich hatte ein Problem und versuchte es mit regulären Ausdrücken zu lösen. Nun habe ich zwei Probleme.

In den Händen eines erfahrenen Anwenders sind reguläre Ausdrücke allerdings äußerst hilfreich.

Sinn regulärer Ausdrücke

Reguläre Ausdrücke dienen der Mustererkennung in Zeichenketten und sind quasi Platzhalter on steroids. Statt der einfachen Platzhalter wie * oder ? z.B. in Dateinamen, gibt es viele verschiedene Platzhalter, Quantifizierer und weitere Regeln, um Muster in Texten zu definieren. Nach diesen Mustern kannst du suchen oder du kannst sie zum Ersetzen von Inhalten benutzen. Teilmuster lassen sich gruppieren und beim Ersetzen wiederverwenden. So gut wie jede Programmiersprache enthält eine eingebaute Unterstützung für reguläre Ausdrücke. Jeder vernünftige Texteditor unterstützt reguläre Ausdrücke beim Suchen und Ersetzen genauso wie eine gute Shell (z.B. Bash oder PowerShell).

Grundlegende Muster

konkreten Zeichen(-folgen): hallo

Bereiche: [], z.B. [a-z], [0-9], [aeiou]

Negation mit ^, z.B. [^abc]

Zeilenanfang: ^ (nicht mit der Negation verwechseln!)

Zeilenende: $

Platzhalter für ein beliebiges Zeichen: .

Alternativen: A|B

Quantifizierer (stehen hinter dem Muster)

einmal oder keinmal (0..1): ?

keinmal, einmal oder mehrmals (0..n): *

einmal oder mehrmals (1..n): +

genaue Anzahl: {8}, {2,5} (2 bis 5 mal)

Gruppen: (), Referenz mit $1

Escapen von besonderen Zeichen (insb. alle obigen): \

Anwendungsfälle aus meiner Praxis

Reguläre Ausdrücke gehören in den Werkzeugkasten jedes ITlers! Egal ob Anwendungsentwicklung oder Systemadministration, reguläre Ausdrücke können vielfältig eingesetzt werden. In der Linux-Administration können z.B. Black- und Whitelists für Hostnamen mit regulären Ausdrücken definiert werden. Die Apache-Konfiguration verwendet ebenfalls reguläre Ausdrücke. Auf der Linux-Kommandozeile kannst du mit grep in Dateien nach regulären Ausdrücken suchen. sed ermöglicht dir die Massenverarbeitung von Dateien. Das Suchen und Ersetzen im vi wird standardmäßig auch mit regulären Ausdrücken gemacht und du kannst sogar mit ihnen navigieren ($ springt z.B. zum Ende der Zeile).

Suchen und Ersetzen in Dateien

Listen umformatieren

Nachname/Vorname zu Vorname/Nachname

Anfang oder Ende von Zeilen manipulieren

Markdown in HTML und umgekehrt

Feldnamen mit public String ; umschließen

Batchdatei generieren zum Verschieben von Dateien

Whitespace trimmen

UUIDs/Domains/Mails in Text/Logs finden

Konkrete Beispiele

Gerade vor wenigen Tagen hatte ich die - eigentlich triviale - Aufgabe, ein paar Dateien umzubenennen, die ein bestimmtes Präfix hatten. Dieses Präfix sollte ausgetauscht werden. Anstatt die Dateien per Hand umzubenennen (oder die entsprechende Shell-Funktion zu nutzen ;-) ), habe ich mir mit einem simplen regulären Ausdruck in wenigen Sekunden ein Shell-Script gebaut, das die Aufgabe für mich löst.

Basis war die Liste der Dateien, die ich in der PowerShell mit dir | ac liste.ps1 erstellt habe.

prefix-Datei1.txt

prefix-Datei2.txt

...

prefix-Datei100.txt

Mit dem Suchen-/Ersetzen-Muster /^(prefix-(.*))$/move $1 neuerPrefix-$2/g im Vim wurde daraus:

move prefix-Datei1.txt neuerPrefix-Datei1.txt

move prefix-Datei2.txt neuerPrefix-Datei2.txt

...

move prefix-Datei100.txt neuerPrefix-Datei100.txt

Die Datei konnte ich dann einfach mit .\liste.ps1 ausführen und war fertig!

UUIDs suchen

Text: Text mit UUIDs wie z.B. 550e8400-e29b-11d4-a716-446655440000 mittendrin

RegEx: [a-f0-9]{8}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{12}

Um die Ermittlung und Dokumentation von Anforderungen für Projekte geht es in der einhundertneunundfünfzigsten Episode des IT-Berufe-Podcasts.

Inhalt

Spätestens für das Abschlussprojekt im dritten Ausbildungsjahr müssen alle Azubis in den IT-Berufen Anforderungen ermitteln. Wen man dabei berücksichtigen sollte, wie man die Anforderungen erhebt und wie man sie verständlich dokumentiert, das erkläre ich hier.

Qualität

Beginnen wir zunächst mit den Anforderungen selbst. Dabei starte ich gerne mit dem Begriff der Qualität. Qualität ist definiert als Übereinstimmung mit den Anforderungen. Dabei können diese Anforderungen von sehr unterschiedlichen Personen oder Personengruppen gestellt werden. Daher ist es wichtig, alle am Projekt beteiligten Personen zu befragen.

Anforderungen

Es gibt grundsätzlich zwei verschiedene Arten von Anforderungen: funktionale und nicht-funktionale. Funktionale Anforderungen beziehen sich direkt auf die zu erbringende Leistung des Produkts, bspw. die Möglichkeit, Text in einer Textverarbeitungssoftware fett darzustellen.

Nicht-funktionale Anforderungen beschreiben den ganzen Rest "drumherum", also z.B. die Performance, Sicherheit, Stabilität, Fehlertoleranz, Benutzbarkeit usw. Sie sind meistens sehr schwer zu definieren, da sie oftmals nicht bewusst wahrgenommen, sondern einfach erwartet werden. Daher werden sie oft vergessen oder können nur schwer quantifiziert werden. Es ist unsere Aufgabe als Projektleiter diese Anforderungen trotzdem so gut es geht zu dokumentieren, damit es am Ende kein böses Erwachen gibt, wenn sie nicht umgesetzt sind.

Eine gute Übersicht über die zahlreichen möglichen nicht-funktionalen Anforderung bietet die Norm ISO 9126, die den Begriff der Softwarequalität definiert.

Stakeholder

Wer definiert überhaupt die Anforderungen an eine Software (oder allgemein an ein zu fertigendes Produkt)? Ein Stakeholder ist jede Person, Gruppe oder Institution, die an dem zu entwickelnden Produkt oder dessen Herstellungsprozess in irgendeiner Weise – positiv oder negativ – interessiert ist.

Hier kommt eine nicht vollständige Liste möglicher Stakeholder unserer Projekte.

Kunde: Der Kunde bezahlt uns für das Projekt. Seine Anforderungen sollten wir auf jeden Fall berücksichtigen.

Anwender: Der Anwender ist die Person, die letztendlich mit unserem Produkt täglich arbeiten muss.

Management: Auch das Management könnte Anforderungen an unser Produkt stellen.

Marketing: Aus dem Bereich des Marketings kommen Anforderungen wie die Corporate Identity.

Entwickler: Die Entwickler haben ganz eigene Anforderungen, wie z.B. eine Versionverwaltung.

Support: Der Support muss nach Einführung des Produkts den Anwendern Hilfestellung leisten und bringt seine ganz eigenen Anforderungen mit.

Gesetzgeber: In fast jedem Projekt gilt es auch bestimmte Gesetze und Richtlinien einzuhalten.

Standards: Gerade in der IT gibt es eine Fülle von Standards, an die wir uns halten sollten, z.B. HTTP für Webserver.

Auditoren: Wirtschaftsprüfer und andere Auditoren stellen ebenfalls Anforderungen an unsere Software, wie z.B. die Nachvollziehbarkeit von Benutzeraktionen.

Kulturkreis: Auch der Kulturkreis, in dem die Software eingesetzt wird, hat bestimmte Anforderungen. So kann sich z.B. die Sprache je nach Land deutlich unterscheiden.

Methoden zur Anforderungsermittlung

Wenn wir wissen, wenn wir nach Anforderungen fragen müssen, ist die nächste Aufgabe, die Anforderungen auch wirklich aus diesen Menschen herauszukommen. Dafür gibt es neben dem Interview auch verschiedene weitere Methoden.

Interview: Die einfachste Methode ist wohl, den Stakeholder direkt zu befragen.

Selbstaufschreibung: Wenn dies nicht möglich ist, kann er seine Anforderungen auch selbst verschriftlichen.

Fragebogen: Etwas mehr Struktur bietet dabei eventuell ein vordefinierter Fragebogen.

Brainstorming: Gerade zu Beginn eines Projekts kann sich ein Brainstorming zur allgemeinen Definition von Anforderungen anbieten.

Um den Buchclub zu Funktionale Programmierung in Java geht es in der einhundertachtundfünfzigsten Episode des IT-Berufe-Podcasts.

Inhalt

Die folgenden Inhalte werden im Buch besprochen. Meiner Meinung nach sollte jeder Azubi zum Fachinformatiker Anwendungsentwicklung diese Begriffe wenigstens einmal gehört haben, besser noch sie mit eigenen Worten erklären können. Die funktionale Programmierung ist neben der Objektorientierung heutzutage sicherlich eine gängige Vorgehensweise.

Für die anderen IT-Berufe sind viele Inhalte sicherlich etwas zu speziell. Allerdings sollte jeder ITler zumindest die verbreiteten Programmierparadigmen auseinanderhalten können. Und dazu zählen meiner Meinung nach auch einige wichtige Schlagworte. So wie bei der Objektorientierung Vererbung und Polymorphie erklärt werden müssen, sollte man bei der funktionalen Programmierung Funktionen höherer Ordnung oder reine Funktionen erläutern können.

Grundlagen

Lambda-Ausdrücke: Anonyme Funktionen in einer kurzen Schreibweise, meist mit einem "Pfeil" als Trenner zwischen Methodenkopf und -rumpf (z.B. ->).

Typinferenz: Implizite Ableitung der Datentypen z.B. von Funktionsparametern aus dem Kontext, z.B. var text = "Text" (text ist "automatisch" ein String).

Algebraische Datentypen

Produkttypen: Der Datentyp wird definiert durch die Kombination verschiedener Werte. Das sind letztlich unsere bekannten Objekte bzw. Structs.

Summentypen: Der Datentyp wird definiert als Liste möglicher Alternativen bzw. Varianten, z.B. ist eine Krankenversicherung entweder eine GesetzlicheKrankenversicherung oder eine PrivateKrankenversicherung. Hierbei müssen die Alternativen nicht in einer Vererbungsbeziehung stehen, wie man am Beispiel vermuten könnte.

Pattern Matching: Kontrollstruktur, die Datentypen "zerlegen" kann. Quasi switch "on steroids".

Generics: Datentypen, die mit anderen Datentypen parametriert werden können. Sie bieten allgemeingültige Algorithmen an, die auf mehreren Datentypen ausgeführt werden können.

Ko- und Kontravarianz: Legen fest, welche Verallgemeinerungen bzw. Spezialisierungen bei Typparametern von generischen Klassen erlaubt sind. Beispiele:

Kovarianz: List students = new List();

Kontravarianz: List students = new List();

Prinzipien der funktionalen Programmierung

Funktionsobjekte (first class citizens): Funktionen sind fester Bestandteil der Sprache und können z.B. Variablen zugewiesen oder als Parameter übergeben werden.

Reine Funktionen (pure functions): Funktionen haben keine Seiteneffekte. Sie liefern zum gleichen Input immer den gleichen Output.

Funktionen höherer Ordnung (higher order functions): Funktionen, die andere Funktionen zurückgeben oder als Parameter bekommen.

Bedarfsauswertung (lazy evaluation): Ein Ausdruck wird erst dann ausgewertet, wenn sein Wert auch wirklich benötigt wird.

Unveränderbarkeit (immutability): Bestehende Werte sollen nicht mehr verändert werden. Stattdessen werden immer neue Werte erzeugt.

Rekursion (recursion): Das Mittel der Wahl zur Iteration ohne veränderliche Variablen.

Referentielle Transparenz (referential transparency): Ein Ausdruck kann jederzeit durch seinen Wert ersetzt werden und umgekehrt.

Funktionale Datenstrukturen

Funktoren: Bieten die Funktion map() an, um den enthaltenen Datentypen in einen anderen zu transformieren. Beispiel: Optional.

Monoide: Mit Monoiden kann man eine Menge von Elementen zu einem Gesamtergebnis verknüpfen, es also reduzieren (fold). Dafür wird ein neutrales Element und eine Reduktionsfunktion benötigt. Beispiel: Addition ganzer Zahlen mit neutralem Element 0.

Monaden: Bieten die Funktionen of() und flatMap() an, um den enthaltenen Datentypen in einen anderen zu transformieren, wobei das Ergebnis dieser Transformation selbst wieder eine Monade ist. Beispiel: Stream.

Listenverarbeitung mit Streams

Grundlagen von map(), filter() und reduce.

Parallele Streams und Eignung von Aufgaben für die Parallelisierung

Um den Unterschied zwischen Datenschutz, Datensicherheit und Datensicherung geht es in der einhundertsiebenundfünfzigsten Episode des IT-Berufe-Podcasts.

Datenschutz vs. Datensicherheit vs. Datensicherung

In dieser Episode werden die drei Begriffe zunächst oberflächlich erläutert und abgegrenzt. Über jedes einzelne Thema kann man aber noch im Detail sprechen und Prüflinge müssen sich auch intensiv damit auseinandersetzen.

Die Begriffe klingen zwar sehr ähnlich, sind aber klar voneinander abzugrenzen und insb. in Prüfungen sauber auseinanderzuhalten. In der Novellierung der IT-Berufe im Jahr 2018 wurden die Begriffe Datenschutz und Datensicherheit explizit in den Ausbildungsrahmenplan mit aufgenommen. Und auch in der Neuordnung 2020 gehören sie zum festen Bestandteil der Berufsausbildung in den IT-Berufen.

Datenschutz

Datenschutz ist der Schutz personenbezogener Daten natürlicher Personen vor Missbrauch durch Dritte.

Personenbezogene Daten sind laut DSGVO "alle Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person [...] beziehen; als identifizierbar wird eine natürliche Person angesehen, die direkt oder indirekt, insbesondere mittels Zuordnung zu einer Kennung wie einem Namen, zu einer Kennnummer, zu Standortdaten, zu einer Online-Kennung oder zu einem oder mehreren besonderen Merkmalen identifiziert werden kann, die Ausdruck der physischen, physiologischen, genetischen, psychischen, wirtschaftlichen, kulturellen oder sozialen Identität dieser natürlichen Person sind". Beispiele: Name, Adresse, IP-Adresse, Bankdaten, Gesundheitsdaten, Standortdaten.

Das Recht auf informationelle Selbstbestimmung sichert jedem Bürger das Recht zu, über die Verwendung seiner Daten selbst zu bestimmen.

Das sogenannte Recht auf informationelle Selbstbestimmung wurde vom Bundesverfassungsgericht im Volkszählungsurteil von 1983 aus dem Grundgesetz abgeleitet. Dort heißt es:

Jeder hat das Recht auf die freie Entfaltung seiner Persönlichkeit, soweit er nicht die Rechte anderer verletzt und nicht gegen die verfassungsmäßige Ordnung oder das Sittengesetz verstößt. (Grundgesetz, Artikel 2, Satz 1)

Warum ist das wichtig? Menschen sollen in ihrer persönlichen Freiheit nicht eingeschränkt werden. Sie würden sich aber ggfs. anders verhalten, wenn anderen Menschen (zu) persönliche Daten über sie bekannt wären, wie z.B. Krankheiten oder sexuelle Vorlieben. Außerdem würden viele Menschen sich einschränken, wenn sie befürchten müssten, dass ihr Verhalten protokolliert würde.

Das Grundgesetz gewährleistet jeder Bürgerin und jedem Bürger das Recht, über Verwendung und Preisgabe seiner persönlichen Daten zu bestimmen (Grundrecht auf informationelle Selbstbestimmung). Geschützt werden also nicht Daten, sondern die Freiheit der Menschen, selbst zu entscheiden, wer was wann und bei welcher Gelegenheit über sie weiß. (Bundesbeauftragter für den Datenschutz und die Informationsfreiheit)

Die EU formuliert es noch deutlicher:

Jede Person hat das Recht auf Schutz der sie betreffenden personenbezogenen Daten. (Grundrechtecharta der EU, Artikel 8, Satz 1)

Seit 2018 gilt die DSGVO, die europaweit strenge Richtlinien zum Datenschutz und auch empfindliche Strafen bei Verstößen definiert.

Prüfungs- und praxisrelevante Inhalte

Obige Definitionen, insb. personenbezogene Daten

Begründung und Verständnis, warum Datenschutz wichtig ist

Kernaussagen der DSGVO

Betroffenenrechte: Auskunftsrecht, Berichtigung, Löschung, Datenübertragbarkeit, Widerspruchsrecht

Pflichten von datenverarbeitenden Unternehmen, "goldene Regeln" des Datenschutzes: Rechtmäßigkeit, Einwilligung, Zweckbindung, Erforderlichkeit, Transparenz, Datensicherheit, Kontrolle

ggfs. Berücksichtigung des Datenschutzes beim eigenen Abschlussprojekt

Datensicherheit

Datensicherheit umfasst alle technischen und organisatorischen Maßnahmen, die dem Schutz von Daten dienen. Dabei handelt es sich nicht nur um personenbezogene Daten.

Law of Demeter (LoD)

Um das Law of Demeter (Gesetz von Demeter) in der Softwareentwicklung geht es im achten Wissenshäppchen.

Inhalt

Das Law of Demeter sagt aus, dass eine Methode nur Zugriff auf die folgenden Objekte/Methoden haben sollte:

Andere Instanzmethoden in ihrer eigenen Klasse

Ihre Parameter

Methoden in Objekten, die sie selbst erzeugt

Globale Variablen

Eine einfache andere Definition lautet: Verkette keine Methodenaufrufe ("method chaining"). Oder: Verwende nicht mehr als einen ., wenn du auf etwas zugreifst. Ein anderer Name für das LoD ist "Prinzip des geringsten Wissens" ("principle of least knowledge").

Der Name stammt von Demeter, einer griechischen Göttin. Der "Erfinder" des Prinzips entwickelte in den 80er-Jahren ein System mit diesem Namen.

Erklärung

Vorweg: Globale Variablen waren in den 80ern hip, heute nicht mehr. Bitte verwende sie am besten gar nicht.

Je mehr "Punkte" in einer Aufrufhierarchie auftreten, desto mehr Kenntnis hat eine Komponente vom "Innenleben" der aufgerufenen Komponenten.

Je mehr Kenntnis eine Komponente über die von ihr verwendeten Komponenten hat, desto stärker bindet sie sich an diese. Wenn sich die genutzten Komponenten ändern, muss sie sich mit ändern bzw. ist kaputt.

Das verletzt das Geheimnisprinzip und die Kapselung, nach der wir eigentlich in der Objektorientierung arbeiten wollen.

Je mehr solcher Abhängigkeiten eine Methode hat, desto schwerer ist sie zu verstehen und zu testen.

Code, der sich an das LoD hält, gilt auch als "schüchtern", weil er "nur mit seinen Freunden spricht".

Beispielcode

Um an den Gesamtbeitrag einer Versicherungspolice zu kommen, ist die Kenntnis über die darin enthaltenen versicherten Personen und deren Tarife nötig. Da es sich dabei jeweils um Listen handelt, ist sogar noch ein "Flachklopfen" der Strukturen nötig. Der Code sieht vielleicht cool aus, ist aber stark an die Strukturen gekoppelt. Das heißt, ein Test müsste sehr viel Aufwand betreiben, um die nötigen Strukturen zu schaffen (z.B. mit Mocks).

class Tarif

def initialize(name)

@name = name

end

def beitrag

123.45

end

end

class VersichertePerson

def initialize(name)

@name = name

@tarife = [ Tarif.new("KFZ"), Tarif.new("Hausrat") ]

end

def tarife

@tarife

end

end

class Versicherungspolice

def initialize

@versicherte_personen = [ VersichertePerson.new("Stefan Macke"), VersichertePerson.new("Klaus Meyer") ]

end

def versicherte_personen

@versicherte_personen

end

end

# cool, aber schwer verständlich, anfällig für Anpassungen und auch schwer zu testen

puts Versicherungspolice.new

.versicherte_personen

.flat_map { |vp| vp.tarife }

.inject(0){|summe,tarif| summe + tarif.beitrag }

Um dies zu vermeiden, können die einzelnen Klassen von ihren inneren Strukturen abstrahieren und stellen simple Zugriffsmethoden für die gewünschten Ergebnisse bereit. Der finale Aufruf sieht nun schon fast langweilig aus. Dafür liegt die fachliche Berechnungslogik da wo sie hingehört: in den jeweiligen Klassen und nicht beim Aufrufer.

class Tarif

def initialize(name)

@name = name

end

def beitrag

123.45

end

end

class VersichertePerson

def initialize(name)

@name = name

@tarife = [ Tarif.new("KFZ"), Tarif.new("Hausrat") ]

end

def beitragssumme

@tarife.inject(0){|summe,tarif| summe + tarif.beitrag }

end

end

class Versicherungspolice

def initialize

@versicherte_personen = [ VersichertePerson.new("Stefan Macke"), VersichertePerson.new("Klaus Meyer") ]

end

def gesamtbeitrag

@versicherte_personen.inject(0){|summe,vp| summe + vp.beitragssumme }

end

end

# langweilig, aber einfach zu verstehen und zu testen

puts Versicherungspolice.new.gesamtbeitrag

Vorteile

Der Code wird verständlicher, weil nicht mehrere Strukturen bekannt sein müssen.

Fachliche Logik landet evtl. eher da,

Um den effektiven Umgang mit Suchmaschinen wie Google zur Recherche von Informationen geht es in der einhundertsechsundfünfzigsten Episode des IT-Berufe-Podcasts.

Inhalt

Warum ist die richtige Suche im Internet wichtig?

Reines Faktenwissen ist nicht mehr zeitgemäß. Dafür haben wir Suchmaschinen.

Die "falsche" Suche führt dich ggfs. zu veralteten oder falschen Informationen. Das behindert dich in der täglichen Arbeit.

Gerade für ITler ist die Suchmaschine ein tägliches Werkzeug. Wir können nicht alle Programmiersprachen oder Konfigurationseinstellungen auswendig kennen.

Es ist wichtig, dass du deinen Verstand bemühst und die Ergebnisse bewertest. Überlass der Suchmaschine nicht das Denken für dich!

Wie "google" ich richtig? Allgemeine Tipps zum Umgang mit Suchmaschinen.

Denk nicht wie ein Mensch, sondern wie eine Maschine! Formuliere also keine Prosatexte, sondern kurze und knappe Suchanfragen mit den wichtigsten Suchbegriffen. Statt "Wie öffne ich eine Datei in Java?" solltest du nach "java datei öffnen" suchen.

Suche so spezifisch wie möglich, indem du einschränkende weitere Suchbegriffe hinzufügst. Statt "java dateiverarbeitung" solltest du nach "java datei schreiben anhängen", wenn du etwas an eine Datei anhängen möchtest.

Verwende gerade im IT-Umfeld Englisch als Sprache für deine Suchanfragen. Das wird zu deutlich mehr Ergebnissen führen. Statt "java datei öffnen" solltest du also nach "java file open" suchen.

Vermeide sogenannte Stopwords und Satzzeichen, die von der Suchmaschine ohnehin ignoriert werden. Statt "how do i open a file in java?" solltest du also nach "java file open" suchen.

Manchmal kann es sinnvoll sein, "anonym" zu suchen, damit die Suchergebnisse nicht anhand deines Profils angepasst werden oder die Suchmaschine ein solches von dir erstellt.

Produktivitätstipps

Ignoriere Groß-/Kleinschreibung bei deiner Suche. Die Suchmaschine ignoriert das eh.

Stelle deine Browser-Suche direkt auf deine Standard-Suchmaschine ein, z.B. Google. Dadurch kannst du durch die Eingabe von Suchbegriffen in der Adresszeile direkt eine Suche starten.

Richte dir Such-Abkürzungen für häufig verwendete Suchmaschinen im Browser ein. Dadurch kannst du mit wenigen Tastendrücken direkt in der gewünschten Suchmaschine suchen. Das geht auch für interne Anwendungen wie dein Ticket-System.

Es gibt nicht nur Google! Je nachdem, was du suchst, kann die direkte Suche bei YouTube oder Amazon sinnvoller sein. Und wenn du umweltbewusster suchen willst, empfehle ich dir Ecosia.

Bewertung von Suchergebnissen

Unterscheide zwischen organischen und bezahlten Suchergebnissen. Erstere sind meist die bessere Wahl.

Platz 1 ist nicht automatisch das beste Ergebnis für dich. Viele Websites verdienen ihr Geld mit Suchmaschinenoptimierung und tun alles dafür, auf den ersten Plätzen zu landen. Sie müssen aber nicht unbedingt den besten Inhalt bieten.

Öffne auch mal die zweite Suchergebnisseite. Im sogenannten Long Tail verbergen sich durchaus auch Perlen.

Achte auf das Erstelldatum der Seite. Gerade in der IT sind aktuelle Inhalte wichtig.

Achte auf korrekte Versionen der verwendeten Software. Eine Anleitung zu Java 6 hilft dir nicht, wenn du mit Java 11 arbeitest.

(Google-)Suchoperatoren zur treffgenaueren Suche

Unpassende Wörter ausschließen: -. Beispiel: javascript dom -react

Exakt passende Treffer (wörtliche Suche): "". Beispiel: "Einhaltung der Präsentationszeit" fachinformatiker

Bestimmte Website durchsuchen: site:. Beispiel: site:it-berufe-podcast.de presenter

Seiten mit Verlinkung auf Zielseite suchen: link:. Beispiel: link:it-berufe-podcast.de

Konkreten Bestandteil der URL suchen: inurl:. Beispiel: projektdokumentation inurl:gerda

Konkreten Dateityp suchen: filetype:. Beispiel: filetype:pdf projektdokumentation vorlage

Schnell kurze Definitionen finden: define:. Beispiel: define:REST

Zusätzliche Möglichkeiten der Google-Suche

Bilder-Rückwärtssuche, z.B. für Quellenangaben bei verwendeten Bildern.

In dieser Sonder-Episode des IT-Berufe-Podcasts geht es um drei Stellenausschreibungen für Softwareentwickler und Systemadministratoren bei meinem Arbeitgeber.

Inhalt

Bei meinem Arbeitgeber, der ALTE OLDENBURGER Krankenversicherung AG aus Vechta, suchen wir zum nächstmöglichen Zeitpunkt Unterstützung im IT-Bereich. Wir schreiben aktuell drei Stellen aus: zwei Softwareentwickler und einen Systemadministrator. Selbstverständlich sind Bewerbungen von Personen aller Geschlechter erwünscht.

Kurzübersicht der Stellen

* Bezeichnung: Softwareentwickler (m/w/d) bzw. Systemadministrator (m/w/d)

* Art der Anstellung: unbefristete Festanstellung

* Arbeitsort: ALTE OLDENBURGER Krankenversicherung AG, Alte-Oldenburger-Platz 1, 49377 Vechta

* Beginn: schnellstmöglich

* Ende der Bewerbungsfrist: 05.07.2020

* Gehalt: attraktive Vergütung nach dem Tarifvertrag für das private Versicherungsgewerbe

* Sonderleistungen: Urlaubs- und Weihnachtsgeld (13,3 Gehälter), Fahrtkostenzuschuss zur Arbeitsstelle, 40 EUR vermögenswirksame Leistungen pro Monat, Firmenfitness über qualitrain, Mitarbeiterrabatte für Versicherungen, arbeitgeberfinanzierte Direktversicherung

* Wöchentliche Arbeitszeit: 38 Stunden im Gleitzeitmodell ohne Kernarbeitszeit (bei einer Vollzeitbeschäftigung)

* Jährlicher Urlaubsanspruch: 30 Tage

* Weiterbildungsmöglichkeiten: (Duales) Studium (z.B. Wirtschaftsinformatik, technische Informatik), IHK-Weiterbildungen, externe Technologieschulungen, Konferenzbesuche

* Sonstiges: frisches Obst, kostenloser Kaffee, modern und ergonomisch ausgestattete Arbeitsplätze in max. 4er-Büros, betriebliche Gesundheitsförderung, eine kostenfreie Rückenmassage pro Monat (außerhalb der Arbeitszeit), ein hervorragendes Betriebsrestaurant mit bezuschussten Speisen, ein Employee-Assistance-Program, viele gemeinsame Aktivitäten wie z.B. Weihnachtsfeier, Betriebsausflug oder Spargelessen

Technische Highlights der Arbeit bei der AO

* Moderne IT-Infrastruktur

* Windows 10 und SUSE Linux

* Virtualisierung mit Citrix und VMware

* Moderne Softwareentwicklung

* Continuous Integration und Deployment

* Test Driven Development, Unit-Tests, Codeanalyse mit SonarQube

* Java 14, Jakarta EE 8, JBoss EAP 7.3

* Fokus auf optimale Kollaboration

* Code Reviews, Pair Programming, Pull Requests

* Fokus auf DevOps

* Gute Zusammenarbeit zwischen Administration und Entwicklung

* Auf- und Ausbau der Container-Infrastruktur mit Docker und Kubernetes

Detailinformationen zu den drei Stellenangeboten

Unter den folgenden Links kannst du dir alle Details zu den ausgeschriebenen Stellen anschauen und findest auch die notwendigen Daten für deine Bewerbung bei uns.

Softwareentwickler für Java-Services

Um die Vorteile und Einsatzgebiete von Plain-Text-Markup-Formaten für längere Texte geht es in der einhundertfünfundfünfzigsten Episode des IT-Berufe-Podcasts.

Inhalt

Plain-Text-Formate sind Formate, die in reinen (menschenlesbaren) Text-Dateien abgelegt werden, also keine binären Formate wie z.B. in Microsoft Word oder LibreOffice.

Vorteile von Plain-Text-Formaten

Versionierung: Diff, Merge, Branches möglich

Langlebigkeit: Keine proprietäre Bearbeitungssoftware nötig, keine Abhängigkeit von Herstellern

Produktivität: Arbeit ausschließlich mit der Tastatur ohne Maus

Flexibilität: Konvertierbar, zur Not selbst parsbar, mit jedem beliebigen Editor änderbar

Automatisierung: Mächtige Tools zur Manipulation vorhanden

Beispiele für Formate

Markdown

leicht zu lernen, geringer Sprachumfang

Output hauptsächlich HTML

breite Unterstützung in Tools, z.B. Wordpress, GitHub

AsciiDoc

sehr großer Sprachumfang, sogar geeignet für Bücher

viele verschiedene Output-Formate, z.B. HTML, PDF, EPUB

gut in übliche Build-Prozesse integriert, z.B. in Gradle

Textile

ähnelt der Wiki-Syntax

Redmine

LaTeX

komplettes Textsatz-System, "perfekter" Textsatz

geeignet für komplette Bücher inkl. Verzeichnissen, Index, Literaturverzeichnis

PlantUML

Gestaltung von UML-Diagrammen

kann u.a. in LaTeX und AsciiDoc eingebunden werden, aber auch in Wikis

Tools

Pandoc: Konvertiert automatisch Dateien zwischen beliebigen Formaten

VSCode: Editor für beliebige Markup-Formate inkl. Preview-Funktion

MarkdownPad: Editor für Markdown

Quelltextbeispiele

Es folgen Beispiele für das gezeigte HTML-Fragment in den unterschiedlichen Markup-Sprachen.

HTML

Markup-Sprachen: HTML

Überschrift

Listen

Links

Bilder

Bildbeschreibung

Code

public static void main(String[] args) {

System.out.println("Hallo!");

}

Zitate

Markdown

# Markup-Sprachen: Markdown

Ein normaler Absatz in Markdown.

## Überschrift

**Fetter Text** und *kursiver Text*.

## Listen

* Ungeordnete Liste

* Mit Unterpunkten

* Noch ein Unterpunkt

* Noch ein Punkt

1. Geordnete Liste

1. Mit Unterpunkten

2. Noch ein Unterpunkt

2. Noch ein Punkt

## Links

[IT-Berufe-Podcast](https://it-berufe-podcast.de "Website des IT-Berufe-Podcasts")

## Bilder


## Code

Inline Code mit `code`.

\```java

public static void main(String[] args) {

System.out.println("Hallo!");

}

\```

## Zitate

> Zitate sehen so aus.

AsciiDoc

== Markup-Sprachen: AsciiDoc

Ein normaler Absatz in AsciiDoc.

=== Überschrift