Komponente | – Logik (.ts) – Vorlage HTML (.html) – Style (.scss) |
Decorator | Technisch: Funktion mit vorangestelltem @-Symbol Anwendung: Klassen, Eigenschaften, Methoden und Parameter Beispiel: @HostListener(‘click’) onHostClick(){/**/} |
Direktiven | Strukturelle Direktiven: manipulieren den DOM (Asterix *) Beispiel: <img *ngIf=”doShowImage”> Attribut-Direktive: verändert das Verhalten oder Aussehen eines Elementes Beispiel: <input matInput> <textarea matAutosizeMinRows =”2″> <input [ngClass]=”inputClass”> |
Pipes | Funktionalität für die Manipulation der Ausgabe (meinstens Verwendung in der VIew) Syntax: Ausdruck | Pipename : Parameter Beispiele: <h2> {{greateTitel | uppercase}}</h2> <h2> {{amount | currency : ‘CHF’ | lowercase}}</h2> |
angular/core | Basis – Kernfunktionalitäten, “Grundlagen” – Komponenten und Direktiven – Lebenszyklus – Pipes – Dependency Injection |
angular/common | Bereitstellung allgemeiner Features – standard: Pipes, Direktiven |
angular/platform-browser (AOT) angular/platform-browser-dynamic (JIT) | Steuert Browser und DOM-relevante Bestandteile zum Rendern von Elementen und Verwalten von Ereignissen |
angular/platform-server | SSR – Server side rendering Ideal für Suchmaschinen und Bots |
angular/http | Client-Server-Kommunikation |
angular/forms | Stellt Features für die Formularnutzung zur Verfügung Vorlagen getrieben: FormsModule (Feste Struktur der Formulare) Reaktiv: ReactiveFormsModule (Dynamische Struktur der Formulare) |
angular/router | Ermöglicht die Steuerung und Konfiguration von Routen für Single-Page-Applications Zuordnung Pfad -> Komponente Unter dem <router-outlet Beispiel: Pfad -> auth Komponente -> app-login <router-outlet></router-outlet> <app-login>…</app-login> |
angular/animate | angular/platform-browser/animations Brücke zwischen der Web-Animations-API und der Angular-Welt |
Kategorie: Sammelsurium
24.02.2022
An den Frieden denken, heisst an die Kinder denken.
Wikipedia: Michail Sergejewitsch Gorbatschow
Der 24.02.2022 beweist wieder einmal mehr wie dumm der Mensch sein kann. Leider nichts aus der Geschichte gelernt.
Warum kämpft man nicht gemeinsam gegen den grössten Feind, der alle Menschen bedroht? Vielleicht wäre es sinnvoller, die Ressourcen zum Retten unseres Planeten Erde zu verwenden, anstelle sich gegenseitig abzuschlachten?
Zum Glück hat die Geschichte uns auch folgendes gelernt:
“Hochmut kommt vor dem Fall”
So long, and thanks for all the fish
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
Repos | Sourcecode-Speicher mit History |
Commits | Schappschüsse des Filesystems |
Commit History | Verkettung der Schnappschüsse / Commits |
Root Commit | Das allererste Commit |
Branches | Verzweigung |
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
![](https://www.monsterli.ch/wp-content/uploads/2021/08/grafik-4.png)
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 log | Zeigt History an |
git log — online | Zeigt verkürzte History an |
git checkout <Hashwert> | Wechselt den Head-Pointer auf den Commit mit dem <Hashwert> |
git checkout master | Setzt 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 branch | Alle 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”
- git checkout master
- git merge <Branch-Name>
Visialisierungen mit GitViz
![](https://www.monsterli.ch/wp-content/uploads/2021/08/grafik-5.png)
![](https://www.monsterli.ch/wp-content/uploads/2021/08/grafik-6.png)
![](https://www.monsterli.ch/wp-content/uploads/2021/08/grafik-7.png)
Arbeiten mit Git Remote-Server
Push | Übermittelt lokale Änderungen auf den Server |
Fetch | Holt Änderungen vom Remote-Server ab |
Pull | Holt Änderungen vom Remote-Server ab und integriert diese im eigenen Code |
Clone | Erstellt 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 –verbose | Zeigt den verwendete Kurzname / URL des Repos an (Meist: origin) |
git push | Übermittelt die lokalen Commits zum Remote-Server |
git pull | Holt 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
![](https://www.monsterli.ch/wp-content/uploads/2021/08/grafik-8.png)
Konflikt zwischen Server und lokalem Repo korrigieren
- git status -> zeigt an wo die Probleme sind
- Problem in den Dateien beheben -> werden durch Kommentare von Git hervorgehoben
- git add <Dateiname> -> Änderungen korrigiert
- git commit -m “<Bemerkung>”
- 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
A | Advanced |
B | Business |
A | Application |
P | Programming |
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
![](https://www.monsterli.ch/wp-content/uploads/2021/07/grafik-2.png)
Change the visibility from the instance attribute to protected
![](https://www.monsterli.ch/wp-content/uploads/2021/07/grafik-3.png)
To inheriting a class do:
CLASS <name> DEFINITION
INHERITING FROM <class_to_inheriting_from>.
Abstract Class
Define a base class as abstract
![](https://www.monsterli.ch/wp-content/uploads/2021/07/grafik-5.png)
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 |
![](https://www.monsterli.ch/wp-content/uploads/2021/07/grafik-6.png)
1 | Paket |
2 | Unterpaket |
3 | Globale Klassen eines Unterpaketes |
4 | Programme (Reports) eines Unterpaketes |
5 | Program (Report) mit Klassen, Felder usw. |
Prüfen, aktivieren und ausführen
![](https://www.monsterli.ch/wp-content/uploads/2021/08/image.png)
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 TESTING | mark as an unit test class |
DURATION | SHORT MEDIUM LONG |
RISK LEVEL | HARMLESS (no changes to data or settings) DANGEROUS (date may changed) CRITICAL (data or settings may be changed) |
CL_ABAP_UNIT_ASSERT | Evaluating test results |
Elementare Datentypen
c | Textfeld | Fixe länge |
N | Nummern Textfeld | Fixe länge |
D | Datumsfeld | Fixe länge |
T | Zeitfeld | Fixe länge |
X | Hexadezimal | Fixe länge |
P | Gepackte Zahl | Fixe länge |
I | Integer | Fixe länge |
F | Float | Fixe länge |
STRING | Text | Variable Länge |
XSTRING | Byte | Variable 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
https://github.com/SAP/styleguides/blob/main/clean-abap/cheat-sheet/CleanABAPCheatSheetV1.4.1.pdf
Meine Notizen zum SAP ABAP-Debugger
Meine Notizen zu SAP Transaktionen
Transaktioncode => Shortcut to a program and a screen
Ausführen:
eingabe <Transaktioncode>
![](https://www.monsterli.ch/wp-content/uploads/2021/07/grafik.png)
Ausführen in einem neuen Fenster:
/o<Transaktioncode>
Transaktions | Beschreibung |
SE80 | Object Navigator (Entwicklungsumgebung) Object Navigator |
SE38 | ABAP Editor ABAP Editor |
SM30 | Tabellenpflege (Pflegedialog) Tabellenpflege |
ST22 | ABAP-Dumpanalyse (Fehlersuche / Laufzeitfehler) ABAP-Dumpanalyse |
SE11 | Data Dictionary (Datenbank) Data Dictionary |
SE16N | Data Browser (Tabelleninhalt bearbeiten) Data Browser |
STMS | SAP Transport Management System (Übersicht) STMS |
SE10 | Transportauftrag Transportorganizer |
SM50 | Workprozessübersicht Workprozessübersicht SAP |
SM51 | Liste der SAP-Systeme Liste der SAP-Systeme |
SE91 | Nachrichtenpflege Nachrichtenpflege |
SENUM | Nummernkreispflege Nummernkreispflege |
SE93 | Transaktionspflege Transaktionspflege |
ST05 | Performance-Trace Performance-Trace |
Shortcuts
F1 | SAP Hilfe |
F3 | Zurück |
Shift + F3 | Beenden |
F8 | Ausführen |
F12 | Abbrechen |
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 – 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
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
- Scrum Master
- 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
- Product Backlog
Nützliche Links
Meine Notizen zu Scrum – Rollen
Meine Notizen zu Scrum – Events