Ich habe das Google Pixel 7 Pro vor kurzem gekauft und bin sehr zufrieden mit dem Smartphone. Es läuft sehr flüssig und sieht auch gut aus. Die abgerundete Bauweise macht es angenehm in der Hand und das Curved Display ist kaum noch vorhanden, was ich bevorzuge.
Die Software des Pixel 7 Pro gefällt mir auch sehr gut. Die Benutzeroberfläche ist benutzerfreundlich und intuitiv und bietet auch einige Personalisierungsmöglichkeiten.
Die Kamera des Pixel 7 Pro ist auch sehr gut. Der Zoom bei 10x ist klar und scharf und der Zoom bei 30x ist auch gut. Die Selfie-Kamera macht auch schöne Bilder.
Insgesamt bin ich sehr zufrieden mit dem Pixel 7 Pro und würde es jedem empfehlen, der nach einem hochwertigen und leistungsstarken Smartphone sucht. Der Preis ist zwar etwas hoch, aber ich denke, dass das Smartphone den Preis wert ist.
Um End-To-End-Tests mit Cypress und Angular zu schreiben, können Sie folgende Schritte ausführen:
Stellen Sie sicher, dass Sie die neueste Version von Cypress und Angular installiert haben. Sie können Cypress mit dem Befehl npm install -D cypress installieren.
Öffnen Sie Cypress mit dem Befehl npx cypress open im Hauptverzeichnis Ihres Projekts. Cypress öffnet eine Benutzeroberfläche, in der Sie Ihre Tests aufzeichnen und ausführen können.
Erstellen Sie eine neue Testdatei, indem Sie auf „Add test file“ in der Cypress-Benutzeroberfläche klicken. Sie können die Testdatei auch manuell im Verzeichnis „cypress/integration“ erstellen.
Fügen Sie den folgenden Code in Ihre Testdatei ein, um sicherzustellen, dass Cypress Ihre Angular-Anwendung erfolgreich geladen hat:
describe('My First Test', () => {
it('Does not do much!', () => {
cy.visit('http://localhost:4200');
cy.contains('app-root h1', 'Welcome to my-app!');
});
});
Führen Sie den Test aus, indem Sie auf die Testdatei in der Cypress-Benutzeroberfläche klicken. Wenn alles erfolgreich war, sollte der Test grün markiert werden.
Erstellen Sie weitere Tests, indem Sie Schritte und Assertions hinzufügen. Sie können Elemente auf der Seite auswählen und auf sie interagieren, indem Sie die Methoden von Cypress verwenden, z.B. cy.get(), cy.click() und cy.type().
Um Cypress mit einem Docker-Container zu verwenden, können Sie folgende Schritte ausführen:
Erstellen Sie eine Dockerfile in Ihrem Projektverzeichnis mit den folgenden Inhalten:
FROM cypress/browsers:node18.6.0-chrome105-ff104
# Install your application's dependencies
COPY package.json yarn.lock ./
RUN yarn
# Add your application code
COPY . ./
# Run the tests
CMD ["yarn", "cy:run"]
Erstellen Sie ein Docker-Image mit dem Befehl docker build -t my-app .
Führen Sie einen Container auf Basis des Images mit dem Befehl docker run -it --rm -v $(pwd):/app my-app aus. Dies führt die Cypress-Tests innerhalb des Containers aus.
Durch das Hinzufügen von -v $(pwd):/app werden Ihre Projektdateien in den Container gemountet und Cypress kann auf sie zugreifen.
Clean Code: A Handbook of Agile Software Craftsmanship ist ein Buch von Robert C. Martin, auch bekannt als „Uncle Bob“. Das Buch, das ursprünglich 2008 veröffentlicht wurde, ist ein Leitfaden für die agile Softwareentwicklung und richtet sich an Softwareentwickler, die sauberen, lesbaren und wartbaren Code schreiben wollen.
Im Buch werden Konzepte und Best Practices beschrieben, die dazu beitragen, dass Code einfacher zu verstehen und zu pflegen ist. Dazu gehören unter anderem die Verwendung eindeutiger Namen für Variablen und Funktionen, das Vermeiden von redundanter oder wiederholter Code sowie die Aufteilung von Code in kleine, wiederverwendbare Funktionen.
Die folgenden Regeln sind neben vielen anderen enthalten und werden sehr gut erläutert:
Verwende eindeutige und beschreibende Namen für Variablen, Funktionen und Klassen.
Vermeide redundante oder wiederholter Code, indem du ihn in Funktionen oder Methoden auslagern.
Trenne Verantwortlichkeiten und logische Abschnitte deines Codes in verschiedene Klassen oder Module auf.
Verwende Kommentare, um den Zweck und die Absicht deines Codes zu erläutern.
Schreibe Tests für deinen Code, um seine Korrektheit und Zuverlässigkeit zu überprüfen.
Vermeide Überladung von Funktionen und Methoden, um Verwirrung beim Aufruf zu vermeiden.
Verwende Konstanten anstelle von Hardcoded Werten, um Code lesbarer und wartbarer zu machen.
Vermeide „Magische Zahlen“ und „Magische Strings“ in deinem Code und verwende stattdessen Konstanten oder Enumerations.
Vermeide unveränderliche Zustände und globale Variablen, da sie schwer zu testen und zu verstehen sind.
Schreibe sauberen Code, indem du kleine Schritte und regelmäßiges Refactoring nutzt, um ihn lesbar und wartbar zu halten.
Ein wichtiger Aspekt von Clean Code ist die Testbarkeit. Das Buch betont, dass Code nur dann als sauber angesehen werden kann, wenn er leicht testbar ist und durch Tests nachgewiesen werden kann, dass er korrekt funktioniert. Dies hilft nicht nur, Fehler frühzeitig zu entdecken, sondern auch dabei, sicherzustellen, dass Änderungen am Code nicht unbeabsichtigte Auswirkungen haben.
Insgesamt bietet Clean Code eine umfassende Anleitung für die agile Softwareentwicklung und ist ein wertvoller Ratgeber für alle, die sauberen, wartbaren Code schreiben wollen.
Das Tool rector ist eine Konsolenanwendung für automatisiertes Refactoring von PHP Anwendungen.
Damit lassen sich schnell einfache Altlasten entfernen aus Legacy Projekten.
Mit dem folgenden Rector Script (./rector.php) können die gängigsten Refactorings durchgeführt werden:
<?php
declare(strict_types=1);
use Rector\Config\RectorConfig;
use Rector\Php81\Rector\Property\ReadOnlyPropertyRector;
use Rector\Set\ValueObject\SetList;
use Rector\Strict\Rector\Empty_\DisallowedEmptyRuleFixerRector;
// run with: vendor/bin/rector process --debug --dry-run
return static function (RectorConfig $rectorConfig): void {
$setLists = [
/*SetList::PHP_52,
SetList::PHP_53,
SetList::PHP_54,
SetList::PHP_55,
SetList::PHP_56,
SetList::PHP_70,
SetList::PHP_71,
SetList::PHP_72,
SetList::PHP_73,
SetList::PHP_74,
SetList::PHP_80,
SetList::PHP_81,*/
//SetList::CODE_QUALITY,
//SetList::CODING_STYLE,
//SetList::DEAD_CODE,
SetList::RECTOR_PRESET,
/*SetList::INSTANCEOF,
SetList::EARLY_RETURN,
SetList::NAMING,
SetList::PRIVATIZATION,
SetList::STRICT_BOOLEANS,
SetList::STRICT_BOOLEANS,*/
];
foreach ($setLists as $setList) {
$rectorConfig->import(
$setList
);
}
$rectorConfig->paths([
__DIR__.'/src',
__DIR__.'/tests',
]);
$rectorConfig->skip([
// do not make all constructor args readonly for mocking and unit tests
ReadOnlyPropertyRector::class,
// using empty() is fine
DisallowedEmptyRuleFixerRector::class,
]);
};
ausführbar im Dry mode ohne Änderungen am Code mit:
Single-Sign-On ist das Thema der Stunde, es verbessert die Sicherheit und auch die User Verwaltung. Um Saml SSO in Symfony einzubauen gibt es das OneloginSaml Bundle, ein Symfony Wrapper für das php-saml Packet.
Der Vorteil für die Benutzer von SSO liegt darin, dass diese sich morgens einmal authentifizieren müssen und danach den ganzen Tag alle Anwendungen verwenden können ohne sich nochmals einloggen zu müssen.
Der Vorteil für das Unternehmen liegt darin, dass es vorgeben kann, dass die Authentifierung nur mit 2 Faktor Authentifizierung stattfinden kann (z.B. Handy App und Passwort), um mehr Sicherheit zu gewährleisten. Dies kannn in der Zukunft den steigendenden Sicherheitsbedürfnissen angepasst werden. Außerdem können zentral Rechte vergeben werden für User und nach dem Austritt aus dem Unternehmen einfach wieder entzogen werden.
Wenn das Bundle installiert und korrekt konfiguriert ist, benötigt man eine Dev-Umgebung mit einem Identity Provider (IdP). Dafür bietet sich docker-simplesamlphp an:
Das OneloginSaml Bundle muss folgender Maßen konfiguriert werden:
hslavich_onelogin_saml:
# Basic settings
idp:
# Identifier of the SP entity (must be a URI)
entityId: 'http://localhost:8080/simplesaml/saml2/idp/metadata.php'
singleSignOnService:
url: 'http://localhost:8080/simplesaml/saml2/idp/SSOService.php'
binding: 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect'
singleLogoutService:
url: 'http://localhost:8080/simplesaml/saml2/idp/SingleLogoutService.php'
binding: 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect'
x509cert: 'insert certificate here'
# Service Provider Data that we are deploying.
sp:
entityId: 'http://localhost/saml/metadata'
assertionConsumerService:
url: 'http://localhost/saml/acs'
binding: 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST'
singleLogoutService:
url: 'http://localhost/saml/logout'
binding: 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect'
privateKey: ''
Die Informationen kann man hier ablesen, auch die vom Zertifikat:
Wenn man alles richtig konfiguriert hat, dann landet man beim Aufruf der Symfony Anwendung auf der Login Seite des IdP Providers und kann sich dort einloggen:
Die Logins lauten:
admin: secret
user1: password
user2: password
Dann sollte man sich mit seiner Symfony Applikation lokal über SAML einloggen und testen können.
Unter Windows oder Linux können für z.B. github.com oder gitlab.com mehrere SSH Keys verwendet werden, um sich mit unterschiedlichen Accounts auf derselben Domain verbinden zu können.
In der ssh config Datei unter ~/.ssh/config können beide SSH Keys angeben werden mit unterschiedlichen Host Einträgen.
Die Host Einträge kann mann selber vergeben und sie müssen unterschiedlichen sein:
Um einen Unit Test von einer Angular Komponente mit Abhängigkeiten (Dependencies) schreiben zu können, muss man die Abhängigkeiten unter Kontrolle bringen.
Wenn man dies nicht tut, schreibt man einen Integration-Test. Integration-Tests haben eine höhere Komplexität hat und gehen schneller kaputt.
Beipsiel einer Komponente „MyComponent“ mit einer Abhängikeit „MyService“:
Um in einem Jasmine Unit Test die Abhängigkeit von MyService zu kontrollieren, kann man einen Spy einsetzen, der an die die Stelle der Methode MyService::getValue gesetzt wird und die Sachen macht, die man für den Test gern hätte.
describe('MyComponent', () => {
let component: MyComponent;
let fixture: ComponentFixture<MyComponent>;
let myService:MyService;
beforeEach(async () => {
await TestBed.configureTestingModule({
declarations: [MyComponent,],
}).compileComponents();
});
beforeEach(() => {
fixture = TestBed.createComponent(MyComponent);
component = fixture.componentInstance;
myService = TestBed.inject(MyService);
});
it('spy should set value', () => {
spyOn(myService,'getValue').and.returnValue('foo');
fixture.detectChanges();
expect(component.serviceValue).toBe('foo');
});
});
In dem Beispiel wird die Methode getValue der Klasse MyService mit einem Spy überschrieben und dem Spy mitgeteilt, dass er den Wert ‚foo‘ zurückgeben soll.
Die Aufgabe ist es eine REST API zu erstellen mit AWS API Gateway, welche Daten lesen und später auch schreiben kann von einer Dynamo DB ohne eine Lambda Funktion zu verwenden.
Wir werden das API Gateway so konfigurieren, dass es die Request Daten validiert und so verändert, dass der DynamoDB Service die Daten verarbeitet.
Dazu erstellen wir in AWS ein nicht private REST API:
Berechtigungen vergeben, dass das API Gateway auf die DynamoDB Tabelle zugreifen kann in AWS IAM. Dafür erstellen wir eine Richtlinie in IAM. Die Berechtigung sieht wie folgt aus:
Dann muss eine Rolle mit der Richtlinie für den Service API Gateway erstellt werden in IAM. Hinweis: Die Richtlinie kann erst nach dem erstellen der Rolle hinzugefügt werden.
Dann Erstellen wir in AWS API Gateway eine Resource mit der Richtlinie: