chore: Add instructions

README.md

@@ -0,0 +1,31 @@
+# Zadanie Rekrutacyjne
+
+Projekt jest w całości zdockeryzowany - wymagany docker compose. Projekt testowałem jedynie na linuksie, ale powinien działać także na innych systemach.
+
+## Uuchomienie
+```bash
+# Skrypt, który odpali composera w tymczasowym kontenerze, zainstaluje zależności a następnie uruchomi projekt
+$ ./bin/start.sh
+```
+
+### Testy
+Testy są napisane w phpunicie (tam gdzie testowanie jednostkowe miało sens) oraz w behacie (tam, gdzie chciałem przetestować integracyjnie). Oba zestawy testów
+można uruchomić jednym poleceniem:
+
+```bash
+$ ./bin/test.sh
+```
+
+### Uwagi
+1. Robiłem jedynie to, co jest opisane w zadaniach - przykładowo dla zadania z saldem klienta zapewniłem jedynie, że jest ono zapisywane w sposób trwały - nie tworzyłem żadnych endpointów pozwlających na odpytanie o to saldo.
+2. W zadaniu 35 z przesyłaniem informacji do CRM pozwoliłem sobię na zmianę kodu HTTP z 400 na 422, który semantycznie zdaje mi się być bardziej poprawny. Ponieważ jest to styk z frontendem to taka zmiana powinna być możliwa do wdrożenia, gdyby to była końcówka wywoływana przez CRM takiej zmiany bym pewnie nie wdrażał.
+3. Założyłem, że walutą jest złotówka (lub inna waluta "dziesiętna"). Tam gdzie kwoty były podawane jako int uznałem, że mamy styczność z groszami (bo tak byłoby najbardziej poprawnie) tam, gdzie były to liczby zmienno-przecinkowe założyłem złotówki.
+4. Waga założyłem, że jest podawana w kg.
+5. Założyłem, że "co najmniej 5 produktów" oznacza "Co najmniej 5 różnych produktów".
+6. Nie robiłem żadnej autoryzacji - zakładam, że odpowiednie mechanizmy są już w aplikacji dostępne i gotowe do użycia.
+7. Architekturę starałem się trzymać jak najprostszą, jednak sugerując się kontekstem zadania uważam, że w przypadku rzeczywistym należałoby ją trochę zmienić - całość wygląda jakby fajnie się implementowała jako jakaś architektura eventowa.
+8. Zadania robiłem w kolejności takiej, jaka zdawała mi się najbardziej odpowiednia - zakładam, ze w rzeczywistości też miałbym wgląd do backlogu i możliwość pewnej dowolności.
+9. W walidacji zamówienia jest wyraźnie mowa o saldzie dodatnim - a nie wystarczającym. Oprogramowałem to zgodnie ze spisanymi wymaganiami, jednak w rzeczywistości upewniłbym się, czy na pewno chcemy pozwalać wchodzić na dowolny debet. Wszak zamówienie może być warte milion, a klient może mieć saldo wynoszące 1 grosz.
+10. Zadania 39, 40 zrobiłem przy okazji dla dopełnienia zestawu testowego ;)
+11. Nie celowałem w pokrycie testami 100% ani nic, pisałem testy, gdzie uznałem za słuszne.
+12. Pewnie przydaloby się jakieś logowanie w aplikacji ale z doświadczenia logi najlepiej dodawać na podstawie konkretnych sytuacji aby nie spamić

bin/start.sh

@@ -0,0 +1,5 @@
+#!/usr/bin/env bash
+
+docker compose run --rm --entrypoint="" -u "$(id -u):$(id -g)" symfony composer install
+docker compose up --build -d
+

bin/test.sh

@@ -0,0 +1,5 @@
+#!/usr/bin/env bash
+
+docker compose exec -u "$(id -u):$(id -g)" symfony ./vendor/bin/phpunit
+docker compose exec -u "$(id -u):$(id -g)" symfony ./vendor/bin/behat
+

docker-compose.yaml

@@ -10,9 +10,10 @@ services:
       - ./:/var/www
 
   symfony:
-    build:
-      context: ./
-      dockerfile: Dockerfile
+    build: .
+    depends_on:
+      mariadb:
+        condition: service_healthy
     command: ["php-fpm"]
     volumes:
       - ./:/var/www
@@ -20,6 +21,10 @@ services:
   mariadb:
     image: mariadb:10.7
     restart: unless-stopped
+    healthcheck:
+      test: mysql $$MYSQL_DATABASE -u$$MYSQL_USER -p$$MYSQL_PASSWORD -e 'SELECT 1;'
+      retries: 120
+      interval: 1s
     ports:
       - "3306:3306"
     environment: