Verstehen von Monolog Log Leveln

Beim Loggen mit Monolog gibt es verschiedene Log Level:

  • DEBUG (100): Detailed debug information.
  • INFO (200): Interesting events. Examples: User logs in, SQL logs.
  • NOTICE (250): Normal but significant events.
  • WARNING (300): Exceptional occurrences that are not errors. Examples: Use of deprecated APIs, poor use of an API, undesirable things that are not necessarily wrong.
  • ERROR (400): Runtime errors that do not require immediate action but should typically be logged and monitored.
  • CRITICAL (500): Critical conditions. Example: Application component unavailable, unexpected exception.
  • ALERT (550): Action must be taken immediately. Example: Entire website down, database unavailable, etc. This should trigger the SMS alerts and wake you up.
  • EMERGENCY (600): Emergency: system is unusable.

Diese sind gewichtet von einfach (Debug = 100 Punkte) bis schwer (Emergency = 600 Punkte). weiterlesen…

Twig Extension zum Sortieren von Entitäten per Datetime Property

Wenn man im Template eine Doctrine Collection sortieren will nach einem Zeitstempel (createdAt in dem Beispiel), sollte man dies eigentlich vorher machen.

Wenn dies nicht möglich ist, z.B. im Sonata Admin Bundle, dann kann man diese Twig Extension verwenden:

{% foo| sortByCreatedAt('asc') %}

Twig Extension Code:

<?php

namespace App\Twig;

use App\Entity\Tag;
use Doctrine\ORM\PersistentCollection;
use Twig\Extension\AbstractExtension;
use Twig\TwigFilter;

class AppExtension extends AbstractExtension
{
    public function getFilters()
    {
        return array(
            new TwigFilter('sortByCreatedAt', array($this, 'sortByCreatedAt')),
        );
    }

    /**
     * @param PersistentCollection $objects
     * @return mixed
     */
    public function sortByCreatedAt($objects, $direction = 'asc')
    {
        $objects = $objects->toArray();
        usort($objects, function ($a, $b) use($direction) {
            if ($direction === 'asc') {
                return $a->getCreatedAt() >  $b->getCreatedAt();
            } elseif ($direction === 'desc') {
                return $a->getCreatedAt() <  $b->getCreatedAt();
            } else {
                throw new \Exception('unknown sort direction');
            }

        });
        return $objects;
    }
}

Strato und MySQL: General error: 1709 Index column size too large. The maximum column size is 767 bytes.

Bei einem Kunden wurde mir folgende Fehlermeldung angezeigt, wenn ich versucht habe über Symfony die Datenbank erstellen zu lassen:

General error: 1709 Index column size too large. The maximum column size is 767 bytes.

Dies liegt daran, das Strato so komische Einstellung bei ihren Managed Hosting Packete wie z.B. das STRATO PowerWeb hat. Strato wird diese Einstellung leider nicht ändern, aber man kann in Symfony in der doctrine.yaml (config.yaml) das Charset ändern, dann funktioniert Symfony auch auf einem Strato Server:

doctrine:
    dbal:
        # configure these for your database server
        driver: 'pdo_mysql'
        server_version: '5.6'
        charset: utf8
        default_table_options:
            charset: utf8
            collate: utf8_general_ci

Symfony Security Passwörter hashen mit dem PasswordEncoder

Der PasswordEncoder des Symfony Frameworks ist sehr gut geeignet auch in Zukunft sichere Hashes von Passwörtern in der Datenbank zu speichern und zentral zu konfigurieren.

Das SecurityBundle muss ggf. nachinstalliert werden:

composer require symfony/security-bundle

Man legt dazu in der security.yaml fest, welchen Hashing Algorithmus man verwenden will für welche Entität:

security:
    encoders:
        App\Entity\User: bcrypt

Die Entität muss das UserInterface implementieren: weiterlesen…

Symfony 3 Test-Datenbank einrichten für Integration Tests

In Symofny wird automatisch beim Ausführen von Tests die  app/config/parameters_test.yml geladen.
Dort sollte dann eine andere Datenbank angegeben werden, der Einfachheit halber mit demselben Datenbank User:

database_host: same_as_dev
database_port: same_as_dev
database_name: test_db
database_user: same_as_dev
database_password: same_as_dev

Dann müssen auf der Konsole folgende Befehle ausgeführt werden:
Cache leeren:
php bin/console cache:clear –env=test

Datenbank erstellen
php bin/console doctrine:database:create –env=test

Tabellen erstellen
hp bin/console doctrine:schema:update –env=test –force

Dann könnne Fixtures geladen werden und Integration Tests geschrieben werden.

 

Syfmony 3.3. – Wie man ein Repository als Service injeziert mittels Dependency Injection

In Symfony 3 wird standardmäßig immer der EntityManager injected, um dann darüber das entsprechende Repository zur Verfügung zu bekommen.

Meistens wird aber nur genau ein Repository benötigt und der Code und die Tests werden aufgebläht.

Es gibt eine einfach Möglichkeit in der Configuration einen Service von einem Respository zu erstellen:

service.repository.name:
 class: 'AppBundle\Repository\MyEntity'
 factory: 'Doctrine\ORM\EntityManagerInterface:getRepository'
 arguments: ['AppBundle\Entity\MyEntity']

Projekt: baby-taschenrechner.de

Das gerade fertiggestellt Projekt baby-taschenrechner.de beschäftigt sich mit den Fragestellungen rund um die Entwicklung des eigenen Kindes:

  • Wie groß wird mein Kind werden in x-Jahren
  • Wie schwer wird mein Kind in x-Jahren
  • Ist mein Kind zu schwer/zu dünn
  • Welche Kleidergröße wird es wann tragen?

Die Webseite soll Eltern dabei helfen herauszufinden, wann sie welche Kleidergröße kaufen müssen, um im nahenden Winter/Sommer das passende zu Hause zu haben.

Eltern können so einschätzne, ob das Kind zu dünn oder zu dick ist  für ihr Alter/Größe/Gewicht-Verhältnis.

Für die Realiserung wurden folgende Technologien verwendet:

Symfony 3, Docker, MySQL, PHP, GIT, Google Material Design, Amazon AWS

Amazon automatische Preisanpassung Tool

Für einen Kunden habe ich gerade ein Tool entwickelt, mit dem man die Preise der eigenen Waren bei Amazon automatisch anpassen kann.Dabei werden die Angote der Konkurrenz analysiert nach Zustand der Ware und nach Seller Seriösität und dadurch ein fairer Preis bestimmt für die Ware. Es werden alle Daten, die über die API verfügbar sind für die Preisbestimmung mit herangezogen, wie z.B. Seller Feedback (Bewertungen des Händlers), ob Amazon selber verschickt, Versanddauer und vieles mehr.

Das Tool vergleicht optional die Preise zwischen den verschiedenen Amazon Plattformen in Europa (DE, UK, IT, ES, FR) aber auch Plattformen außerhalb Europas, wie Japan oder Amerika und händelt die unterschiedlichen Währungen.

Das Ergebnis kann direkt zu Amazon mittels der API geschickt werden und die Preise werden sofort geupdatet.

Amazon Preisanpassung

Screenshot Preisanpassungs Tool

 

Die Anwendung ist in PHP mit Symfony 3 geschrieben und hat ein Frontend mit Twitter Bootstrap 3 und eine MySQL Datenbank. Außerdem gibt es eine Vagrant Umgebung für die Entwicklung mit PHP7.1 und nginx. Ausgeführt werden kann das ganze mit einer einfachen Xampp Umgebung oder Vagrant Virtual Box beim Kunden lokal auf einem PC.

Falls sie auch Interesse an einem solchen Tool haben, könnne sie gern Kontakt aufnehmen.