Meine Notizen zu Git

Git ist eine moderne plattformübergreifende freie Sourcecodeverwaltungs Software. Git ist sehr flexible und kann auch Offline verwendet werden – lokal auf dem Rechner.

Der Name „Git“ bedeutet in der britischen Umgangssprache so viel wie „Blödmann“. Linus Torvalds erklärte seine Wahl des ungewöhnlichen Namens mit einem Witz sowie damit, dass das Wort praktikabel und in der Softwarewelt noch weitgehend unbenutzt war:

“I’m an egotistical bastard, and I name all my projects after myself. First ‘Linux’, now ‘Git’.”

– Linus Torvalds[6]

https://de.wikipedia.org/wiki/Git

Grundbegriffe

ReposSourcecode-Speicher mit History
CommitsSchappschüsse des Filesystems
Commit HistoryVerkettung der Schnappschüsse / Commits
Root CommitDas allererste Commit
BranchesVerzweigung

Aufbau eines Commits

Filesystem-Schnappschuss
(Files und Verzeichnisse)
Metadaten
(Name, Datum, Kommentar…)
Zeiger auf das letzte Commit
(beim Ersten leer, ansonsten Hashwert des vorhergehenden Commits)
Hashwert
(Aus allen Daten des Commits)

Git – Pointers

HEAD- und MASTER-Pointer zeigen auf den selben Hashwert
1)Head-Pointer
2)Master-Pointer

Basisfunktionen

Version von Git anzeigen:

> git --version
git config –global user.name “<Name>”Festlegen des eigenen Namens
git config –global user.email “<Email>” Festlegen der eigenen Emailadresse
git init <name>Neues Repo mit <name> anlegen
git statusÜberblick über das aktuelle Repo
git add <filename>Änderung hinzufügen (Staging)
git add .Alle neuen Änderungen übernehmen
git commit -m “<Kommentar>”Commit erstellen
git logZeigt History an
git log — onlineZeigt verkürzte History an
git checkout <Hashwert>Wechselt den Head-Pointer auf den Commit mit dem <Hashwert>
git checkout masterSetzt den Head-Pointer wieder auf den Master Branch
git revert <Hashwert> Macht den Commit <Hashwert> rückgänging

Anmerkung: Commit Message wird angezeigt, welche noch geändert werden könnte. Standard Editor VIM mit :qa verlassen
git reset –hard <Hashwert>Abhängen eines Commits aus der History (dangeling)
git branch <name>Neuer Branch erstellen
git branchAlle Branch-Pointer anzeigen
git checkout <Branch-Name>Wechselt in den angegebenen Branch
git merge <Branch-Name> Führt einen merge mit dem <Branch-Name> durch

Mergen – “fast-forward”

  1. git checkout master
  2. git merge <Branch-Name>

Visialisierungen mit GitViz

Head-Pointer zeigt auf einen ältern Commit
Neu erstellter Branch
Branch mit einem neuen Commit

Arbeiten mit Git Remote-Server

PushÜbermittelt lokale Änderungen auf den Server
FetchHolt Änderungen vom Remote-Server ab
Pull Holt Änderungen vom Remote-Server ab und integriert diese im eigenen Code
CloneErstellt eine Kopie auf dem lokalen PC
git clone <URL_Repo>Erstellt eine lokale Kopie des Repos
(Bsp: https://github.com/Readify/GitViz.git)
git remote –verboseZeigt den verwendete Kurzname / URL des Repos an
(Meist: origin)
git pushÜbermittelt die lokalen Commits zum Remote-Server
git pullHolt alle Änderungen vom Remote-Server und merged diese ins lokale Repo

Im Beispiel unten, sehen wir ein Repo mit verschiedenen Git-Pointers:

  • HEAD -> Master enthält Änderungen, welche remote noch nicht vorhanden sind
  • Die Pointers “origin/master” und origin/HEAD sind lokal und remote identisch
  • Es gibt einen Branch “origin/netcore”
  • Es gibt einen Tag 1.0.2.0

Konflikt zwischen Server und lokalem Repo korrigieren

  1. git status -> zeigt an wo die Probleme sind
  2. Problem in den Dateien beheben -> werden durch Kommentare von Git hervorgehoben
  3. git add <Dateiname> -> Änderungen korrigiert
  4. git commit -m “<Bemerkung>”
  5. git push -> Konsolidierte Dateien auf remote Server übertragen

Nützliches

Offizielle Git Webseite https://git-scm.com/

Readify GitViz https://github.com/Readify/GitViz

GitHub – Git cheat sheet https://training.github.com/downloads/de/github-git-cheat-sheet/

Git cheat sheet als PDF https://rhoenerlebnis.de/_upl/de/_pdf-seite/git_cheatsheet_de_white.pdf

Meine Notizen zu SAP ABAP

AAdvanced
BBusiness
AApplication
PProgramming

ABAP Concepts:

  • Transaction
  • Programm
    • Manage Business Process
  • Screen
  • Data Dictionary
    • Database
  • Subroutine
    • Divide long programs to a subroutine
  • GUI Status
    • Custom Menus

ABAP Objects

Naming Conventions

  • Customer objects prefixed with “Y” or “Z” (from A to X used by SAP)
  • Object names denote functionality
  • Variable names denote usage
  • Never use literal values (SELECT * from VBAK WHERE AUART IN (‘ZSP0’, ‘ZSP2’).
  • Interfacenames start with IF_* / ZIF_*
  • Variablename: lv_<name> => local variable

Prefixes

lv_local variable
ls_local structure
ty_type (Datastructure)
lt_local table

A Framework Class

Global Class

Inheriting a global class

Remove final attribute from the class to inheriting

Change the visibility from the instance attribute to protected

To inheriting a class do:

CLASS <name> DEFINITION
  INHERITING FROM <class_to_inheriting_from>.

Abstract Class

Define a base class as abstract

Sonstiges

lv_text = TEXT-t01 && | | && lv_text.
Space character in a text&& | | &&
TEXT-<xxx>Textsymbol
*Comment out a line
CLASS <name> DEFINITION
ENDCLASS.
Interface
CLASS <name> IMPLEMENTATION
ENDCLASS.
Class object
CLASS IMPLEMENTATION
INHERITING FROM <class_name>.
ENDCLASS.
Inheriting
METHODES:
show_details REDEFINITION.
Overwriting an inheriting methode
super->show_details( ).Call the methode in the superclass
TRY.
lcl_start=>run ( ) .
CATCH cx_root INTO lcl_start=>mo_error.
ENDTRY.
Unhandled exceptions cause short dumps
1Paket
2Unterpaket
3Globale Klassen eines Unterpaketes
4Programme (Reports) eines Unterpaketes
5Program (Report) mit Klassen, Felder usw.

Prüfen, aktivieren und ausführen

ABAP Unit / Test Classes

CLASS lcl_test DEFINITION
      FOR TESTING
      DURATION SHORT
      RISK LEVEL harmless.

      PRIVATE SECTION.
      DATA: lo_test TYPE REF TO zcl_main "class under test
      METHODES: setup, teardown          "Fixture methodes
      METHODES: test_method1 FOR TESTING "Test method

ENDCLASS.
FOR TESTINGmark as an unit test class
DURATIONSHORT
MEDIUM
LONG
RISK LEVELHARMLESS (no changes to data or settings)
DANGEROUS (date may changed)
CRITICAL (data or settings may be changed)
CL_ABAP_UNIT_ASSERTEvaluating test results

Elementare Datentypen

Elementare ABAP-Typen

cTextfeldFixe länge
NNummern TextfeldFixe länge
DDatumsfeldFixe länge
TZeitfeldFixe länge
XHexadezimalFixe länge
PGepackte ZahlFixe länge
IIntegerFixe länge
FFloatFixe länge
STRINGTextVariable Länge
XSTRINGByteVariable Länge

Lokale Datenstruktur

TYPES: BEGIN OF ty_matdata,
  matnr TYPE c LENGTH 15,
  mattext TYPE c LENGTH 30,
  matunit TYPE c LENGTH 3,
  END OF ty_matdata.

Zuweisung / Nutzung der lokalen Struktur

data ls_matdata type ty_matdata.

ls_matdata-matnr = '1'.

Lokale Tabelle

data lt_material type TABLE OF ty_matdata.

Tabelle befüllen:

do 5 times.

* sy-index => runtime variable mit aktuellem index
  ls_matdata-matnr = sy-index.
  CONCATENATE 'Mein Material' ls_matdata-matnr into ls_matdata-mattext.
  ls_matdata-matunit = 'ST'.
  append ls_matdata to lt_material.

ENDDO.

Tabelle ausgeben:

loop at lt_material into ls_matdata.
* / => Zeilenumbruch  
  write / ls_matdata.
ENDLOOP.

Tabelle ausgeben mit FIELD-SYMBOLS: (Performence)

*&---------------------------------------------------------------------*
* FIELD-SYMBOLS
*&---------------------------------------------------------------------*
FIELD-SYMBOLS <fs_matdata> type any.

loop at lt_material ASSIGNING <fs_matdata>.
* / => Zeilenumbruch
  write / <fs_matdata>.
ENDLOOP.

Wichtige Befehle

DO x TIME.
<code>
ENDDO.
CONCATENATE
APPEND
LOOP AT <table> INTO <record>.
ENDLOOP.
WRITE
DATA <name> TYPE <Datentyp>
IF <Abfrage>. (=, >, <…)
ELSEIF <Abfrage>
ELSE.
ENDIF.
CASE <Variable>.
WHEN <Bedingung>.
WHEN <Bedingung 2>.
WHEN OTHERS.
END CASE.

Open SQL

SELECT * FROM <table> INTO TABLE <lt_name>Einfache Select-Abfrage
SELECT * FROM <table> INTO CORRESPONDING FIELDS OF TABLE <lt_name> Select-Abfrage, welche nur die namensgleichen Felder berücksichtigt

Nützliches

GitHub: SAP Styleguides

https://github.com/SAP/styleguides/blob/main/clean-abap/cheat-sheet/CleanABAPCheatSheetV1.4.1.pdf

Meine Notizen zu SAP Transaktionen

Transaktioncode => Shortcut to a program and a screen

Ausführen:

eingabe <Transaktioncode>

Ausführen in einem neuen Fenster:

/o<Transaktioncode>

TransaktionsBeschreibung
SE80Object Navigator (Entwicklungsumgebung)
Object Navigator
SE38ABAP Editor
ABAP Editor
SM30Tabellenpflege (Pflegedialog)
Tabellenpflege
ST22ABAP-Dumpanalyse (Fehlersuche / Laufzeitfehler)
ABAP-Dumpanalyse
SE11Data Dictionary (Datenbank)
Data Dictionary
SE16NData Browser (Tabelleninhalt bearbeiten)
Data Browser
STMSSAP Transport Management System (Übersicht)
STMS
SE10Transportauftrag
Transportorganizer
SM50Workprozessübersicht
Workprozessübersicht SAP
SM51Liste der SAP-Systeme
Liste der SAP-Systeme
SE91Nachrichtenpflege
Nachrichtenpflege
SENUMNummernkreispflege
Nummernkreispflege
SE93Transaktionspflege
Transaktionspflege
ST05Performance-Trace
Performance-Trace

Shortcuts

F1SAP Hilfe
F3Zurück
Shift + F3Beenden
F8Ausführen
F12Abbrechen

Meine Notizen zu Scrum – Artefakte

Das Product Backlog

Das Product Backlog ist der Schreibtisch, das Product Owners, welches immer aktuell und sauber geführt werden muss. Es ist eine priorisierte Liste mit Anforderungen / Requirements. Es besteht aus den User Stories, welche eine Anforderung in einem Satz erklären, den Akzeptanzkriterien, Schätzung der Komplexität und den Epics (Grosse Anforderungen, welche noch in User Stories aufgeteilt werden müssen)

DEEP- Kriterien

  • Detailed Appropriately (angemessen detailiert)
  • Estimated (geschätzt)
  • Emergent (mehr als eine Summe der Einzelteile)
  • Prioritized (priorisiert)

User Stories

INVEST-Kriterien:

  • Independent (unabhängig)
  • Negitiable (verhandelbar – veränderbar bis in Sprint Backlog aufgenommen)
  • Valueable (werthaltig)
  • Estimable (schätzbar)
  • Small (klein genug)
  • Testable (testbar)

Akzeptanzkriterien

  • Was muss sonst noch beachtet werden (Filterung, Sortierung…)

Möglicher Aufbau:

Als @Rolle@ @möchte ich@ Ziel, so dass @Nutzen@

Nützliche Links

Meine Notizen zu Scrum – Events

Sprint Zero

  • Projektspezifische Aspekte
    • Gemeinsame Vorstellung / Vision erhalten des Produktes
    • Wann und wo werden die Stakeholder eingebunden
    • Risiken, ungefähre Dauer und Kosten
  • Teamspezifische Aspekte
    • Arbeitszeiten, Werte, was ist die Projektsprache
    • Erstellung der
      • Definition of Done (Wann ist eine Anforderunge Fertig?)
      • Definition of Ready (Wie muss der Product Owner eine Anforderung beschreiben?)
  • Organisationsspezifische Aspekte
    • Schlüsseltermine
    • Informationen rund um das Projekt
    • Zusammenkommen mit Stakeholdern

Sprint Planning

  • Dauer von 1 bis 4 Std.
  • Formulierung des Sprint-Ziels
  • Was wird in diesem Sprint Umgesetzt?
    • Wie viele User Stories können im Sprint umgesetzt werden
    • Übernehmen ins Sprint Backlog

Benötigte Vorarbeiten:

  • Vorbereitetes Product Backlog
  • Vorstellung der Anforderungen (User Stories) durch den Product Owner
  • Erstellung des Sprint Backlogs

Daily Scrum Meeting

Ist ein Event für das Development Team. Product Owner und Scrum Master sind nicht zwingend erforderlich. Die Praxis zeigt aber, dass es doch empfehlends Wert ist.

  • Time Box von 15 min.
  • Jeder beantwortet diese Fragen:
    • Was habe ich gestern erreicht, das dem Entwicklungsteam hilft, das Sprint-Ziel zu erreichen?
    • Was werde ich heute erledigen, um dem Entwicklungsteam bei der Erreichung des Sprint-Ziels zu helfen?
    • Sehe ich irgendwelche Hindernisse (Impediments), die mich oder das Entwicklungsteam vom erreichen des Ziels abhalten?

Sprint Review

Am Ende des Sprints stellt das Entwicklungsteam die umgesetzten Anforderungen vor. Der Product Owner nimmt die User Stories ab. Der Scrum Master organisiert und moderiert (bei Unstimmigkeiten Entwicklungsteam – Product Owner) das Review.

  • Wiederholung des Sprint-Ziels
  • Vorstellung der neu gewonnen Funktionalitäten
  • Vorstellung der umgesetzten User Stories
  • Abnahme durch den Product Owner
    • Bei Abnahme: Anforderung gilt als umgesetzt
    • Bei Ablehnung durch eine der Begründungen:
      • Akzeptanzkriterium nicht erfült
      • Punkt der Definition of Done verletzt

Sprint Retrospektive

Für den Scrum Master ist sie das Herzstück des Frameworks. Im Fokus steht hier die Zusammenarbeit im Team und soll aufzeigen, was noch optimiert oder verbessert werden kann. Es sollen nur Personen aus dem Scrum Team teilnehmen.

  • Wie gut haben wir Scrum als Framework bereits adaptiert?
  • Wie läuft unsere Zusammenarbeit?
  • Was hinder uns, Scrum noch besser zu nutzen?

Folgende Regeln sind Zwingend zu befolgen:

Egal was wir heute erkennen, wir sind fest davon überzeugt, dass alle Beteiligten zu jedem Zeitpunkt nach bestem Wissen, Gewissen und Kenntnisstand gehandelt haben.

Norman Kerth, 2001

Was auch immer in Vegas passiert, bleibt in Vegas.

Vegas-Regel

Sprint

  • Für den Scrum Master ist die Impediment-Liste das zentrale Artefakt für die allgemeine Organisation des Sprints
  • Der Scrum Master ist für einen reibungslosen Verlauf des Sprints verantwortlich
  • Der Product Owner sollte für den Rest des Teams zuallersrt als Ansprechpartner immer zu Verfügung stehen
  • Das Development Team sollte sich zuallererst während des Sprints Komplett aus sich selbst und sein Sprint Backlog konzentrieren

Nüztliche Links

Meine Notizen zu Scrum – Kurzüberblick

Meine Notizen zu Scrum – Rollen

Product Owner

Dem Product Owner gehört das Produkt, an dem gearbeitet wird. Er trägt die komplette Verantwortung hinter dem Wert des Produktes. Er ist die Schnittstelle zwischen dem Scrum Team und allen anderen Stakeholdern.

Wichtige Punkte:

  • Mit welchen Anforderungen kann ich den Wert des Produktes für alle Anwender maximieren?
  • Wann wird das Produkt / Inkrement ausgeliefert?

Scrum Master

Scrum Master ist ein Vorbild beim Scrum Prozess, er ist quasi der Motor des Scrum Prozesses.

  • Scrum Experte – Muss immer auf dem neusten Stand sein
  • Change Agent – Bei Einführung von Scrum trägt er eine wichtig Rolle mit
  • Facilitator – Kümmert sich um alle Probleme im Team und löst diese
  • Prozesswächter – Überwacht den Prozess / Rahmen – Events müssen korrekt durchgeführt werden
  • Coach – Moderiert, führt Gespräche

Development Team

Ist eigenverantwortlich für die Umsetzung des vom Product Owner gesetzten Anforderungen. Es muss für die Umsetzung alle benötigten Kompetenzen besitzen – es muss crossfunktional sein.

Nützliche Links:

Meine Notizen zu Scrum – Kurzüberblick

Meine Notizen zu Scrum – Kurzüberblick

Agiles Framework für die Produktentwicklung. Dabei ist das Framework ein leichtgewichtiges Framework und gibt nur einen groben Rahmen vor, lässt jedoch viel Spielraum offen.

Die 5 Prinzipien von Scrum:

  • Kurze Iterationen
  • Selbstorganisation
    • Team kann sich selbstorganisieren
    • Technischeumsetzung liegt in der freiheit des Teams
  • Inspect and Adapt (Überprüfen und Anpassen)
    • Stetige Überprüfung und massnahmen zur Verbesserung
  • Regelmässige Lieferung
    • Dadurch regelmässiges Feedback des Kunden
    • Entwicklung kann immer wieder bestmöglichst angepasst werden
  • Transparenz
    • Alle Aspekte müssen für alle beteiligten transparent sein

Der Rahmen des Framwork besteht aus:

  • Events (regelmässiges Zusammenkommen)
    • Sprint Planning
    • Daily Scrum (Daily Standups ca. 15 min.)
    • Scrum Review
      • Prüfung ob die Anforderungen / Inkremente wirklich umgesetzt wurden
      • Entsprechen sie dem gemeinsamen Verständnis von fertig (Done)
    • Scrum Retrospektive
      • Schliesst den Sprint ab
  • Rollen
    • Scrum Master
      • Coaching Rolle für den Product Owner, Development Team und Organisation, um Scrum zu verinnerlichen
      • Einen Rahmen zu schaffen, in dem jede Person seine Aufgabe bestmöglich ausüben kann
    • Product Owner
      • Für die fachlichen Anforderungen zuständig
      • Pflege des Product Backlog
    • Developmet Team
      • Zuständig für die Umsetzung der fachlichen Anforderungen
  • Artefakten
    • Product Backlog
      • Sammlung aller möglichen Anforderungen (User Stories, Epics) und Inkrementen
    • Sprint Backlog
      • Enthält alle Anforderungen, welche umgesetzt werden
      • Darf sich nie während einem sprint verändern

Nützliche Links

Meine Notizen zu Scrum – Rollen

Meine Notizen zu Scrum – Events

Meine Notizen zu Scrum – Artefakte

wikipedia: Scrum