DEV Community: Simon Benjámin

Számlázz.hu - Számla Agent PHP API - Composer csomag

Simon Benjámin — Sun, 21 Apr 2024 09:02:32 +0000

Az egyik projektben a Számlázz.hu-t használjuk majd a számlázásra, ennek az első lépése a projektbe bekötés, Sandbox környezet létrehozása, néhány teszt számla beküldése.

Számlázz.hu

A Számlázz.hu-nál "Tesztüzemnek" hívják, van róla külön bejegyzés: teszt api hozzáférés. Én ezt választottam, hogy ne az éles rendszerben kelljen sztornózni, hanem legyen egy bármikor elérhető játszós környezet. Szükségünk lesz még egy "Számla Agent kulcs" létrehozására is. Ezt belépés után a Számlázz.hu főoldal alján (a számlák és a fiókhozzáférések) "Számla Agent kulcsok" alatt találjuk meg.

Számla Agent API

A hivatalos dokumentáció (Szamla Agent API) csak egy letölthető .zip csomag linkjére mutat, jelenleg ez a PHPApiAgent-2.10.18.zip.

Frissítési információk itt: changelog (néhány napja jött ki a legfrissebb verzió: [2.10.18] - 2024.04.18)

Kicsit meglepett, hogy nincs hivatalos csomag kiadva amit egyszerűen be lehetne húzni composerrel.

Composer

Van néhány Composeres csomag, de számlázó kódját nem szeretném használni "ismeretlen forrásból". Főleg úgy, hogy, az eredeti kódhoz képest több-kevesebb módosítást is tartalmaznak.

Megnéztem, kipróbáltam, hogy összeállítható-e úgy a csomag, hogy nem kell belenyúlni kézzel és kódot szerkeszteni. Ehhez készült egy PHP script ami mindent megcsinál: szamla-agent-update.php. A PSR-4 kompatibilitás miatt át kellett nevezni néhány könyvtárat és kész működik.

A frissítő script is a repository része, a kiadott verziót a hivatalos verzióhoz igazítottam: v2.10.18

Mivel más is ugyanígy bizonytalan lehet a fenti csomagommal, megpróbálom felvenni a kapcsolatot a Számlázz.hu fejlesztőivel és jelezni, hogy érdemes lenne ezt átaluk hivatalos karbantartott csomagként githubon publikálni.

sudo su remove `personal_access_tokens`

Simon Benjámin — Tue, 30 Jan 2024 20:21:22 +0000

Legacy projekt Laravelesítése

Legacy projekt Laravelesítése (Laravel 8 - mert a PHP verzió adott ahhoz igazodunk) közben futottam bele abba, hogy az üres adatbázis séma létrehozásakor:

php artisan schema:dump
php artisan migrate:refresh

mindenképpen létrejött a personal_access_tokens tábla és a migrációs file:

Nothing to rollback.
Loading stored database schema: /var/www/html/database/schema/mysql-schema.dump
Loaded stored database schema. (49,714.31ms)
Migrating: 2019_12_14_000001_create_personal_access_tokens_table
Migrated:  2019_12_14_000001_create_personal_access_tokens_table (2,930.78ms)

A Laracast fórumában 2 megoldást is találtam a probléma megszüntetésére:

1. `laravel/sanctum` csomag eltávolítása

Valamiért a Laravelben alapból mellékelve van a fenti csomag, egyszerűen távolítsuk el (ha kell droppoljuk a token táblát) és utána a séma frissítésekor nem fog létrejönni a migrációs file:

composer remove laravel/sanctum

2. Ignoráljuk a migrációját

Az AppServiceProvider.php fájlban a register() függvényben hívjuk meg az alábbi parancsot (a fájl elejére a use Laravel\Sanctum\Sanctum;-ot is tegyük oda):

# app/Providers/AppServiceProvider.php

public function register()
{
    // sudo su ne jojjon letre a `personal_access_tokens` migrations
    Sanctum::ignoreMigrations();
}

Mindkettő működik, én a második megoldást választottam. Így talán jobban szem előtt van, miért és hogyan lett "inaktiválva". (A kódban taktikai komment elhelyezésével ha valaki rákeres meg is találja a megfelelő kódrészletet.)

Villámgyors MySQL ORDER BY RAND() lekérdezés

Simon Benjámin — Tue, 03 Oct 2023 16:17:24 +0000

Jelenleg dolgozom egy projekten ahol az adatbázis rendberakása is a feladatom része. Ez több lépéses, több dolgot is érint itt most a véletlenszerű rendezéssel kapcsolatban szeretnék mutatni egy alternatív megoldást.

Bekapcsoltam az adatbázis központi lassú SQL loggolását, így bukott ki, hogy van néhány ORDER BY RAND() SQL amik nem teljesítenek túl jól (azaz szarul teljesítenek 🤣).

Kiinduló állapot

4000 rekordból 9 véletlenszerű elem kiválasztása: ~16 másodperc

Valami hasonló a kiinduló lekérdezés, lecsupaszítva (az EXPLAIN ANALYZE 4-6 másodpercig fut):

SELECT * FROM my_table ORDER BY RAND() LIMIT 9;

Megoldás, részletek

Keresgéltem de nem találtam számomra megfelelő megoldást (túl bonyolultak - ideiglenes tábla - vagy "nem teljesen" random megoldásokkal találkoztam). Így elkezdtem a saját kútfőből összerakni:

Fogjuk a táblát amiből le akarunk kérdezni és kérdezzük le plusz értékként a RAND() értékét is:
```
SELECT id, RAND() AS random_order FROM my_table;
```

Ezt a lekérdezést csomagoljuk egy subselectbe, csináljuk meg rajta a rendezést és a szükséges LIMIT-et kérjük le:

SELECT rnd.id FROM (
    SELECT id, RAND() AS random_order FROM my_table 
) AS rnd ORDER BY rnd.random_order LIMIT 9;

Most a fentit tegyük egy újabb subselectbe és kapcsoljuk az eredeti táblához:

SELECT * FROM my_table AS myt
JOIN (
    SELECT rnd.id FROM (
        SELECT id, RAND() AS random_order FROM my_table 
    ) AS rnd ORDER BY rnd.random_order LIMIT 9
) AS random_list ON random_list.id = myt.id;

Végeredmény

Egy picit hosszabb nem annyira triviális mint az ORDER BY után írni, hogy RAND() de a fő kérdés megéri? Szerintem egyértelműen igen:

Végeredmény ~400x sebesség növekedés:
4000 rekordból 9 véletlenszerű elem kiválasztása: ~0.04 másodperc

EXPLAIN ANALYZE (a sallangokat kitöröltem):

mysql> SELECT COUNT(id) FROM my_table;
+-----------+
| COUNT(id) |
+-----------+
|      4193 |
+-----------+
1 row in set (0.08 sec)

mysql> EXPLAIN ANALYZE SELECT * FROM my_table ORDER BY RAND() LIMIT 9;
------------------------------------------------------------------
  -> Limit: 9 row(s)  (actual time=5233..5235 rows=9 loops=1)
    -> Sort row IDs: rand(), limit input to 9 row(s) per chunk  (actual time=5233..5235 rows=9 loops=1)
        -> Table scan on <temporary>  (cost=18633..18670 rows=2736) (actual time=3694..5232 rows=4193 loops=1)
            -> Temporary table  (cost=18633..18633 rows=2736) (actual time=3694..3694 rows=4193 loops=1)
                -> Table scan on my_table  (cost=18359 rows=2736) (actual time=0.0227..2653 rows=4193 loops=1)
------------------------------------------------------------------
1 row in set (5.24 sec)

mysql> EXPLAIN ANALYZE SELECT * FROM my_table AS myt JOIN ( SELECT rnd.id FROM ( SELECT id, RAND() AS random_order FROM my_table ) AS rnd ORDER BY rnd.random_order LIMIT 9 ) AS random_list ON random_list.id = myt.id;
------------------------------------------------------------------
 -> Nested loop inner join  (cost=11.5 rows=0) (actual time=2.53..4.01 rows=9 loops=1)
    -> Table scan on random_list  (cost=2.5..2.5 rows=0) (actual time=2.2..2.21 rows=9 loops=1)
        -> Materialize  (cost=0..0 rows=0) (actual time=2.2..2.2 rows=9 loops=1)
            -> Limit: 9 row(s)  (actual time=2.19..2.19 rows=9 loops=1)
                -> Sort: random_order, limit input to 9 row(s) per chunk  (actual time=2.19..2.19 rows=9 loops=1)
                    -> Stream results  (cost=18931 rows=2736) (actual time=0.454..1.89 rows=4193 loops=1)
                        -> Covering index scan on my_table using disabled  (cost=18931 rows=2736) (actual time=0.448..1.36 rows=4193 loops=1)
    -> Single-row index lookup on myt using PRIMARY (id=random_list.id)  (cost=1.01 rows=1) (actual time=0.2..0.2 rows=1 loops=9)
------------------------------------------------------------------
1 row in set (0.00 sec)

Éles környezetben is teszteltem a fenti megoldást, valós táblákon:

Test table 1:    321 149 records, time:  0.2512 seconds
Test table 2:    865 706 records, time:  0.3070 seconds
Test table 3: 10 630 486 records, time: 52.1207 seconds

Ami ebből látható: a fenti megoldás 1 millió rekordig működőképes lehet (1 másodpercen belül fut). De azt is tegyük hozzá, hogy nem túl életszerű, hogy több százezer vagy milliós rekordokból kell random adatokat kiszednünk, hanem lesznek más szűrések előtte: aktív adatokra, felhasználóra, stb.

Tetszik, használnád, tudsz jobb megoldást? Írd meg! Köszönöm!

UPDATE: sikerült tovább egyszerűsítenem:

SELECT * FROM my_table AS myt
JOIN (
    SELECT id FROM my_table ORDER BY RAND() LIMIT 9
) AS random_list ON random_list.id = myt.id;

DBeaver MySQL csatlakozás SSH tunnelen keresztül

Simon Benjámin — Fri, 15 Apr 2022 14:32:40 +0000

Verzió információk:

DBeaver: Version 22.0.2.202204041542
MySQL szerver: 8.0.27

Hozzuk létre az új kapcsolatot:

Állítsuk be az SSH tunnelt (1) én készítettem profilt (2), hogy több kapcsolatnál is tudjam ugyanazt az SSH konfigurációt használni, ezt ki lehet hagyni a "Settings"-nél meg lehet adni a szükséges adatokat:

Adjuk meg a bejelentkezéshez az adatokat (2) és teszteljük a kapcsolatot (3):

Eddig jók vagyunk:

"OK" majd "Apply and Close"-al zárjuk be az SSH beállításokat, visszatérünk az adatbázis konfigurációhoz, adjuk meg (1) az előbb létrehozott SSH profilt:

Váltsunk a "Main" tabra és ott adjuk meg (1) az adatbázis eléréshez szükséges adatokat (a tunnel miatt itt a "Server Host" localhost és "Port" pedig a szerveren lévő MySQL - általában alapértelmezett - 3306-os portja), majd teszteljük a kapcsolatot (2):

Itt lehetnek problémák, pl:

nincs engedélyezve a távoli kapcsolat a MySQL szerveren (mysqld.cnf konfiguráció)
a megadott felhasználóval nem tudunk kapcsolódni (mysql adatbázis db, host, user beállításai)
nem megfelelő user + jelszó

Végül pedig amibe belefutottunk:

SSH jó volt (másik kapcsolat működött)
másik adatbázishoz másik felhasználó működött
jó volt a jelszó
beállításaik szinte 99%-ban megegyeztek (db, host, user)

Ezek után ezt a hibát kaptuk: Public Key Retrieval is not allowed a [Driver properties] alatt van egy allowPublicKeyRetrieval kulcs amit módosítottam true/yes-re. Nem oldotta meg, jött a következő: Access denied for user '<USER>'@'<HOST>' (using password: YES).

Itt kezdtem gyanakodni és nyomozni, hogy miben tér el a működő és a nem működő felhasználó beállítása a mysql táblákban. Egyetlen dolog volt ami szóba jöhetett (minden más stimmelt) a user.plugin oszlopnak: caching_sha2_password volt az értéke, a működő felhasználónak pedig mysql_native_password.

Módosítsuk az érintett felhasználó bejelentkezését:

ALTER USER '< USER >'@'< HOST >' 
IDENTIFIED WITH mysql_native_password BY '<*** PASS ***>';

FLUSH privileges;

Ezek után sikeresen tudtam kapcsolódni az adatbázishoz.

Twelve-Factor App módszer a gyakorlatban / 1. rész

Simon Benjámin — Sun, 22 Aug 2021 19:55:20 +0000

A Twelve-factor app alapján fogok pár dolgot az egyik projektemmel kapcsolatban megosztani. Jelenlegi cél a kiinduló állapot feljavítása, kezelhetőbbé tétele. A szokásos: megy a versenyautó és menet közben cserélünk motort. Szépen lépésenként egy jobb, karbantarthatóbb, stabilabb, biztosabb, működőbb környezet és kód felé haladva.
Tanulni, fejlődni, minden nap!

I. Codebase

A kódbázissal nem volt gond, ugyanis nem volt verziókezelve 😎 😆 (meglepő de egy másik projekt kapcsán is pont ezt mesélték, hogy eddig 2 fejlesztő dolgozott és most kezdték verziókelőbe beemelni a kódot) ezt gyorsan lehetett orvosolni egy github repositoryval. Ami még engem zavart, hogy semmi archívum, előzmény nem állt rendelkezésre, hogy mit csinált az előző fejlesztő az elmúlt időszakban.
Szerencsére a szerveren talált mentésekből (havi és napi 1 hétre visszamenőleg) végül sikerült gyártani egy kis verziótörténetet.

II. Dependencies

A függőségek a kódbázissal kéz a kézben jártak, a jövőben Composer-t használunk erre.

III. Config

Itt lesz teendő bőven, minden IS a kódba van égetve. Ezeket szépen el kell kezdeni kiszervezni. Ennek az első lépései megtörténtek. Én régebben az Apache-ban használtam ENV beállításokat, pl:

SetEnv APP_ENV "development"

Ez alapján már a fejlesztőkörnyezetből (Vagrant virtuális gép) az emailek nem kerülnek kiküldésre, hanem a MailHog kapja el őket.

Elkezdtem néhány Bash scriptet készíteni: init, külső programok telepítése (Composer, PHPUnit, PHPCPD, PHPMD és PHP-CS-Fixer) és itt is szükségem lett volna az APP_ENV értékére, ami ugye Apache beállítás és CLI-ben nem elérhető.

Első körben átraktam mindent az /env/environment-be, majd mivel nem akartam ezt a globális részt szemetelni, meg amúgy is szebb elkülönítve, illetve az ebben használt formátumot (APP_ENV=development) az Apache /etc/apache2/envvars nem tudta betölteni / feldolgozni, így a /etc/profile.d/CUSTOM-environment.sh-be kerültek át az adatok, ide viszont már az export APP_ENV=development formában.

Az Apache /etc/apache2/envvars-ban meg simán berántható a fenti file tartalma:

# Load all the CUSTOM environment variables.
. /etc/profile.d/CUSTOM-environment.sh

Így most CLI-ben is megvannak a beállítások és az Apache-on keresztül a PHP is megkapja őket.