Mockito
Based on http://www.vogella.com/tutorials/Mockito/article.html
Mock: Leitet Aufrufe nicht an ein reales Objekt weiter.
Spy: (Proxy) Mockt nur die Methoden-Aufrufe, die gestubbt sind. Den rest leitet er an das „reale“ Objekt weiter.
Siehe auch: Auf reales Objekt zugreifen (Spring Proxy)
Spring AOP Proxy – Auf ein durch Proxy vertretenes Objekt zugreifen
Spätestens sobald eine Spring-Component mit einer Annotation für Caching, Transaktionen oder AOP versehen ist, baut Spring einen Proxy davor.
!Spring baut keinen Proxy for ein jedes dependency injected Bean!
Die Referenz auf das Object, das man sich von Spring „autowiren“ liess, z.B.
@Autowired private MeineSpringComponent meineSpringComponent;
lässt ist dann der Proxy.
Um auf das reale Objekt zuzugreifen ist folgender Code nötig:
public static <T> T getTargetObject(Object proxy) { if (AopUtils.isCglibProxy(proxy) || AopUtils.isAopProxy(proxy)) { try { return (T) ((Advised) proxy).getTargetSource().getTarget(); } catch (Exception e) { e.printStackTrace(); fail(e.getMessage()); return null; } } else { return (T) proxy; } }
Der code prüft zuerst ob es sich um einen Spring-Proxy handelt und gibt, wenn es so ist das dahinter stehende Objekt zurück, wenn nicht jedoch das Input-Objekt selbst.
Wenn man nun also z.B. via Reflection auf ein Feld von meineSpringComponent zugreifen möchte tut man das so:
org.springframework.test.util.ReflectionTestUtils.setField(AOPUtilsHelper.getTargetObject(meineSpringComponent), „nameDesFelds“, „neuer Wert des Feldes“);
[/java]
Reference: Transactions Caching and AOP – Understanding Proxy Usage in-Spring
Maskierung von Sonderzeichen in WordPress
Es können die üblichen HTML-Maskierungen verwendet werden, z.B. > für &
Code in WordPress-Beitrag integrieren
Code muss innerhalb des Plain-Text-Editors in
... code ...
eingepackt werden
Achtung!
Layout ist nur in der Web-Ansicht (nicht Editor-Ansicht) effektiv!
Das Plugin heisst SyntayHighliter
Im WordPress-Dashboard können unter Einstellungen -> SyntaxHighliter einstellungen vorgenommen werden. Dort ist auch ein kleines Anwendungsbeispiel
Set mit einem einzigen Element erstellen
UniqueId instrumentId = new UniqueId(); new HashSet<>(Arrays.asList(instrumentId))
Static Method and Concurrency (MultyThrading) / Java Memory Model
Clarification by user Selig on stackoverflow:
„Memory in java is split up into two kinds – the heap and the stacks. The heap is where all the objects live and the stacks are where the threads do their work. Each thread has its own stack and can’t access each others stacks. Each thread also has a pointer into the code which points to the bit of code they’re currently running.
When a thread starts running a new method it saves the arguments and local variables in that method on its own stack. Some of these values might be pointers to objects on the heap. If two threads are running the same method at the same time they will both have their code pointers pointing at that method and have their own copies of arguments and local variables on their stacks. They will only interfere with each other if the things on their stacks point to the same objects on the heap. In which case all sorts of things might happen. But as Hans points out, Strings are immutable (cannot be changed) so we’re safe if this is the only object being „shared“.
So many threads can be running the same method. They might not be running at the same time – it depends how many cores you have on your machine as the JVM maps Java threads to OS threads, which are scheduled onto hardware threads. You therefore have little control over the way these threads interleave without using complex synchronisation mechanisms.“
Git Workflow
Ressourcen
Wichtigstes: https://rogerdudler.github.io/git-guide/index.de.html
Die Doku: https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging
Tutorial mit typischem WorkFlow: https://product.hubspot.com/blog/git-and-github-tutorial-for-beginners
Schnelle Einführung in Git (auf Deutsch): http://www.andreas-schrade.de/2015/03/11/git-kompakte-einfuehrung/
Eigenes Dokument:
A) Remote- und Local-Repository erstellen
- Repository erstellen
a) Lokal
git init
b) Auf GitHub
–> Irgend so ein „Create Repository“-Button. - Repository einchecken
- Ganzes Repository vom Remote-Repository neu als lokal bewirtschaftete Kopie auschecken:
git clone <Pfad zum Remote-Repository>
Nicht zu verwechseln: git pull (Beziehen von neuerungen im Remote-Repo)
B) Typischer Enwickler-Zyklus (entnommen von da.)
- Für die geplanten Änderungen einen Feature-Branch erstellen und dort hin wechseln:
Zuerst noch letzte Änderungen holen:
git pullgit checkout -b iss53
- Code-Änderungen ins lokale Repository committen:
git commit -a -m 'added a new footer [issue 53]'
(Dies ist die Abkürzung für git add … gefolgt von git commit …)
3. Feature-Branch mit dem Master mergen
Auf den Master wechseln: git checkout master
Letzte Änderungen des Masters holen: git pull
Mergen: git merge iss53
Ich denke das muss gemacht werden, um die Gefahr zu verkleinern, daass während dem folgenden Schritt – merge auf dem Remote-Repository – Merge-Konflikte auftauchen, die dann dort gelöst werden müssen.
Konflikte lösen: Siehe z.B. hier (suche nach Kapitel „Basic Merge Conflicts“)
3. Änderungen/Feature-Branch ins Remote-Repository schicken und dort vorschlagen:
git push origin iss53
Auf GitHub ist der neue Branch nun sichtbar unter „Branches“. Es wird dort dann auch ein Button „Create pull request“ angeboten.
4. Pull-Request erstellen
Button: „Create pull request“
Nach Ausfüllen und Abschicken des Requests ist er sichtbar unter Button „Pull requests“.
5. Pull-Request approven und mergen:
Via Button „Merge“ wird der Feature-Branch auf den Master gemerget.
Feature-Branch von jemand anderm aus dem Remote-Repo holen
- Anzeigen der verfügbaren Branches im Local- und Remote-Repository
git branch -v -a
- Von Repository Master und Branches
git fetch origin
Dann hat man alle Branches des Remote-Repos auch lokal und kann z.B. mit dem Mergen beginnen. Anleitung dazu ist hier.
Lokales Repo: Unterteilung
a) Working Directory:
Dateien auf dem lokalen Rechner, die durch Programmierer verändert werden.
Move von a -> b via: git add
–> Neuer Status der hinzugefügten Dateien: Staged
b) Index / Staging Area:
Ist eine Datei, in der die Aenderungen verzeichnet werden.
Anzeigen, was im Index vorliegt/für commit bereit ist: git status
Move von b -> c via: git commit -m <Aenderungsbeschrieb>
c) Head:
(.git-Verzeichnis) Lokale VCS-Datenbank, mit den der Aenderungshistorie drin (alle Commits) –> 1. .git-Verzeichnis pro Repository
Anzeigen, was im Head ist: git log
Willkürliches Kommando-Listing
- Ausstehende Commits anzeigen (was noch nicht in der Staging-Area und nicht im Feature-Brach ist):
git status - Status des HEAD aschauen:
git log - Branch erstellen
git checkout -b <Branchname> - Branch liefern
git push -u origin <Branchname> - Branch mit Master mergen lokal
1) zum Master wechseln: git checkout master
2) Master aktualisieren: git pull
3) Merge vom Branch: git merge <Branchname> - Zwischen Branches und/oder Master wechseln
git checkout <Branchname> respektive git checkout master - Branches anzeigen:
git branch - Merge bei Konflikten:
Siehe z.B. hier (suche nach Kapitel „Basic Merge Conflicts“) - Update (Beziehen von Neuerungen aus dem Remote-Repository):
git pull