Um die Ldap PHP Extension zu installieren, kann man unter Linux / Ubuntu einfach den Befehl:
sudo apt-get install php-ldap
Kategorie: PHP
PHP Probleme,Tipps und Tricks
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.
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']
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
Wenn man heutzutage einen Webservice bauen will, kommt man um REST nicht mehr herum. Als quasi Standard erfüllt es die Bedürfnisse an eine moderne Schnittstelle am besten, im Gegensatz zu den Alternativen aus der grauen Vergangenheit: RPC, DCOM, CORBA, RMI und SOAP.
Was sind die Vorteile von REST?
1. Lose Kopplung
REST Schnittstellen können theoretisch gegeneinander ausgetauscht werden.
2. Interoperabilität
REST über HTTP ist in jeder Umgebung verfügbar und sehr einfach anzusprechen im Gegensatz zu den komplizierteren Ansätzen wie SOAP und CORBA.
3. Performance und Skalierbarkeit
Durch die Zustandslosigkeit können viele Anfragen aus dem Cache beantwortet werden und aufeinander folgende Anfragen müssen nicht von demselben System beantwortet werden (Skalierbarkeit)
Grundprinzipien von REST
Das letzte Projekt war sehr spannend, es handelte sich um eine Erweiterung des PHP Shop-Systems namens XT-Commerce bzw. des Derivats SEO-Commerce um eine Suche aktuellem Standards für Zeedee Berlin.
Elasticsearch wurde auf einer eigene Amatzon MWS EC2 Instanz gehostet mit 1GB Ram und 1 CPU (sehr kostengünstig).
Die folgende Funktionalität kann ganz einfach wieder deaktiviert werden an zentraler Stelle, wenn es Probleme mit Elasticsearch gibt und die alte MySQL Suche tritt wieder in Kraft.
1. Autocomplete / Suggest Funktion beim Befüllen der Suche
Beim Eintippen des Suchwortes werden schon Vorschläge gegeben im Millisekundenbereich. Dadurch kann der Kunde viel Zeit sparen und bei der Rechtschreibung wird auch geholfen. 
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.
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.
Die Amazon MWS Library hat zu Recht Probleme in PHP7.1 mit der Datei: /MarketplaceWebServiceProducts/Model/ResponseHeaderMetadata.php (line 31)
Vorher:
class MarketplaceWebServiceProducts_Model_ResponseHeaderMetadata {
...
public function __construct($requestId = null, $responseContext = null, $timestamp = null,
$quotaMax = null, $quotaMax = null, $quotaResetsAt = null) {
$this->metadata[self::REQUEST_ID] = $requestId;
$this->metadata[self::RESPONSE_CONTEXT] = $responseContext;
$this->metadata[self::TIMESTAMP] = $timestamp;
$this->metadata[self::QUOTA_MAX] = $quotaMax;
$this->metadata[self::QUOTA_REMAINING] = $quotaMax;
$this->metadata[self::QUOTA_RESETS_AT] = $quotaResetsAt;
}
Nach dem Fix:
public function __construct($requestId = null, $responseContext = null, $timestamp = null,
$quotaMax = null, $quotaMaxRemain = null, $quotaResetsAt = null) {
$this->metadata[self::REQUEST_ID] = $requestId;
$this->metadata[self::RESPONSE_CONTEXT] = $responseContext;
$this->metadata[self::TIMESTAMP] = $timestamp;
$this->metadata[self::QUOTA_MAX] = $quotaMax;
$this->metadata[self::QUOTA_REMAINING] = $quotaMaxRemain;
$this->metadata[self::QUOTA_RESETS_AT] = $quotaResetsAt;
}
Grund ist, dass die Variable $quotaMax doppelt benutzt wird in der Kontrultor Definition.
If you want to develop unit and integration tests with PHPStorm you can easily bootstrap your application and run your tests. But if you want to develop real unit tests in your local development enviroment without having a database connection or a cache, you need to make sure, that your application is configured differently, when unit tests are running. In this article you will learn how to do that and how to make PHPStorm will automatically recognize which tests/tests suites you want to execute.
Requirement:
Your integration and unit tests are seperated in 2 directories, like:
/tests/unitTests /tests/integrationsTests
Overview
If you want to build a search query in Easticsearch where you can give documents a bonus score depending on how often a property can be found in other documents
– you need is a Subquery which is not supported by Elasticsearch, you need another better solution.
An Example for a Subquery is the problem:
Imagine a CD online shop. You want to score CDs ( = documents) higher which
1. match a term query AND
2. and which artist has many other CDs in your shop database
You would need a field, which aggragts the artist count in your mapping (artistCount for Example) and on query time and boost the artistCount field with the score:
{
"query" : {
"custom_score" : {
"query" : {
"match_all" : {}
},
"script" : "_score + (1 * doc.artistCount.integerValue)"
}
}
}It would be also a good idea, to have a second index, which holds the artistCount information, because on every update of the inventory of your shop, the artsitCount needs to be recalculated.