Kategorie: Meine Notizen

Meine Notizen: Angular

Komponente– Logik (.ts)
– Vorlage HTML (.html)
– Style (.scss)
DecoratorTechnisch: Funktion mit vorangestelltem @-Symbol
Anwendung:
Klassen, Eigenschaften, Methoden und Parameter

Beispiel:
@HostListener(‚click‘)
onHostClick(){/**/}
DirektivenStrukturelle 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“>
PipesFunktionalitä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/coreBasis – Kernfunktionalitäten, „Grundlagen“
– Komponenten und Direktiven
– Lebenszyklus
– Pipes
– Dependency Injection
angular/commonBereitstellung 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-serverSSR – Server side rendering
Ideal für Suchmaschinen und Bots
angular/httpClient-Server-Kommunikation
angular/formsStellt Features für die Formularnutzung zur Verfügung

Vorlagen getrieben: FormsModule
(Feste Struktur der Formulare)

Reaktiv: ReactiveFormsModule
(Dynamische Struktur der Formulare)
angular/routerErmö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/animateangular/platform-browser/animations

Brücke zwischen der Web-Animations-API und der Angular-Welt

    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

    Generic report program frameworkHerunterladen

    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 – Kurzüberblick

    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