Symfony „vs” Drupal

php
php-fig
drupal
symfony

Először is szeretném felhívni a figyelmet, hogy a címben jelzett versus idézőjelben van. A cikk pont arról szól, hogy az miért is van úgy írva.

Egy kedves ismerősömmel éppen a szegedi Networkshop 2017 konferenciáról visszafelé tartottunk Budapestre. Valamiről beszélgetni kellett, és igencsak jó téma került elő. A Symfony keretrendszerről kezdtünk beszélgetni, nem ismerte, de lelkes érdeklődő volt, sok-sok kérdéssel. Elmondtam neki mindent töviről hegyire. Elmondtam, hogy ez egy keretrendszer, ami azt jelenti, hogy telepítés után nem tud még semmit, magunknak kell megírni amit szeretnénk. Szóba került a Drupal is, tudja, hogy abban is otthon vagyok. Azt is elmondtam, hogy az meg egy tartalomkezelő, tehát már telepítés után is bőven van hova kattintgatni.

… És akkor feltette a nagy kérdést:

Hogyan lehet a Drupalt és a Symfonyt együtt használni, lehet-e egyáltalán keverni ezeket?

Már majdnem mondtam a standard választ, hogy hát az egyiket lehet telepíteni a másik alkönyvtárába, és akkor bizonyos URL-eket az egyik, a többit meg a másik fogja kiszolgálni. Persze ez nagyon messze van attól, hogy igazán egyszerre használjuk a kettőt. Ezt a fajta egymás mellett élést bármelyik két webes rendszerrel meg lehet tenni, teszem azt akár egy Rails-es alkalmazás és egy java SpringBoot-os alkalmazással is.

De …

… a Symfony és a Drupal ennél sokkal mélyebb integrációja is lehetséges, legalábbis akkor, ha Drupal alatt D8-at értünk. Kedves olvasó, van már ötleted, hogy mire akarok kilyukadni? Ha nincs, akkor mutatom a következő elképzelt „beszélgetést”:

– Hé, Te Symfony! Van ötleted, hogy a felhasználó milyen tartalmat kér most éppen rajtunk számon? Nesze, itt egy Request objektum, benne van az URL, a sütik, a böngésző típusa, és még vagy 28 millió másik dolog.

– Nekem aztán fogalmam sincs, itt egy 404-es Response objektum. Csak most, csak neked, nagy szeretettel.

– Hé, Te Drupal8! Neked csak van valami ötleted, hogy mit akarhat a user, ugye? Itt a Request objektum, tessék.

– Passz, fogalmam sincs. Tőlem is kapsz egy friss – ropogós, 404 Response-t.

– Na, te házilag barkácsolt FityfirityCMS, te már biztosan tudni fogod, hogy mit kér a user.

– Háááát biza`, ötletem az nekem sincs.

– Na jó, Laravel, utoljára téged még megkérdezlek! Neked már tényleg tudnod kéne, mi a fenét akarhat a user.

– Nekem van egy tippem, tessék itt egy Response. Van benne minden, HTTP fejlécek, tartalom, és még sok egyéb jóság. A változatosság kedvéért ez pont nem 404.

PSR-7

Amire utalni próbálok az a PSR-7 ereje. Arról van szó ugyanis, hogy okos emberek kitalálták, hogy legyen egy standard interfész, ami leír egy HTTP kérést és egy HTTP választ. És bármelyik rendszer, ami ezeket az interfészeket implementálja, az tud egymással érdemben kommunikálni, és el tudják dönteni egymás között például azt is, hogy egy adott kérést kinek kellene kiszolgálni. Erre volt egy példa, a fenti kis szösszenet.

Symfony HttpFoundation

A PSR-7 csak egy interface. A Symfony HttpFoundation pedig egy implementációja. Bár nem muszáj ezt használni, bárki újraimplementálhatja a PSR-7-et, csak éppen túl sok értelme nincs. Aki a saját kis keretrendszerét, tartalomkezelőjét, vagy akármilyen egyéb kis szkriptecskéjét úgy építi fel, hogy az a Symfony HttpFoundation-t használja a HTTP kérések és válaszok kezelésére, az alkalmas lesz becsatlakozni és együtt dolgozni minden olyan rendszerrel, ami hasonlóan tesz.

Nincs vége

A beszélgetésünk előtt is ismertem a PSR-7-et és a Symfony HttpFoundation-t, de ez a beszélgetés döbbentett rá ezek igazi erejére és hasznosságára. Ugyanis a történet nem áll meg ott, hogy URL alapján eldöntjük, hogy kinek kell kiszolgálni a kérést. A kooperáció ennél sokkal-sokkal komplexebb is lehet. El tudok képzelni például olyat, hogy a tartalmat a Drupal állítja elő, de az autentikációt a Symfony végzi. Majd az elkészült végleges Response válaszhoz, a saját kis fityfirity alkalmazásunk még hozzá tesz egy extra HTTP fejlécet, amiben a teljes tartalmat egy titkos kulccsal még aláírja. Mi is hallottunk már a HTTPS-ről, de tegyük most fel, hogy az nem elég, annál többet akarunk. És az egész elé még bedobunk egy gyors user sapce reverse proxy-t, amivel gyönyörűen felturbózzuk az alkalmazásunk sebességét. És mindezt okosan, tartalom és user függő módon, nem vagyunk kénytelenek kizárólag az URL-re és az időre hagyatkozni a gyorstárazható-e vagy sem kérdés eldöntésekor.

Összegezve tehát a PSR-7 szabvány és annak implementációja, a HttpFoundation segítségével képesek vagyunk arra, hogy egymástól független, akár egymásról nem is tudó alkalmazások összedolgozzanak azon, hogy a felhasználó által indított HTTP kérésre megszülessen egy válasz. A lehetőségek tárháza ezzel igencsak kitárul. Annak oka, hogy ez nincsen széles körben kihasználva, véleményem szerint mindössze azért van, mert a keretrendszerek és tartalomkezelő rendszerek önmagukban is elég eszközkészletet adnak ahhoz, az átlagos igényeket kielégítsék. De biztosan van olyan eset, amikor erre szükség lehet. Nekem például eszembe is jutott egy alkalmazási lehetőség, amire a Sztakiban biztosan lenne igény. De ez már egy másik mese.

További olvasnivaló:

Legjobb composer csomagok: dátumkezelés a cakephp/chronos-szal

php
composer
dátumok
legjobb composer csomagok

Előszó

Eléggé elhanyagoltam a blogom az elmúlt néhány évben, főleg amióta a Sztakiban dolgozom. Jó sok dologgal megismerkedtem közben, meg hát az informatika és a webes technológiák is változtak közben. Éppen itt az ideje, hogy ismét felvegyem a fonalat, és ellássam tartalommal szeretett kis blogom.

TLDR; goto cool példák

Legjobb composer csomagok

A legjobb Drupal modulok sorozatom elég népszerű volt, sok visszajelzés érkezett azokra a bejegyzésekre. Mivel a 8-as verzió óta már a Drupal is Composer-t használ, azért úgy gondolom ez egy jó téma, amivel érdemes foglalkozni.

Dátumkezelés

Aki fél évnél többet programozott már életében, az valószínűleg belefutott már a dátumok, időpontok és időzónák örökzöld problémájába. Nem elég, hogy vannak nekünk időzónáink – amelyek folyton változnak, téli és nyári időszámításunk és szökőéveink. Mindezekhez, szinte már desszertként, csatlakoznak a szökő-másodpercek is.

Meg sem próbálom ebben a bejegyzésben – vagy bárhol máshol – mindenre kiterjedő leírást adni a dátumok kezeléséhez, a fentiekkel inkább csak érzékeltetni akartam a probléma összetettségét.

Dátumok PHP alatt

A PHP beépített dátum kezelő függvényei kissé suták, egyszerűek. Teszik a dolgukat ugyan, de egy modern OO környezetben egyáltalán nem állnak kézre. Szerencsére van megoldás, két népszerű composer csomag formájában.

A legnépszerűbb a nesbot/carbon nevű csomag, amely messze a legnagyobb telepítési bázissal rendelkezik. Én viszont egy másik csomagot szeretnék bemutatni, a CakePHP közösség Chronos csomagját.

Miért cakephp/chronos?

A csomag kezdőoldala két olyan érvet is említ, amik engem is meggyőztek.

Az objektumok megváltoztathatatlanok, azaz Immutable objektumok. Magam is belefutottam már abba, hogy egy általam használt, de külső fejlesztők által írt, vagy akár ténylegesen általam írt kód megváltoztatott egy dátumot, mert az adott kontextusban már nem volt jelentősége a régi értéknek. Igen ám, de a hívó még szeretett volna dolgozni a régi értékkel, miközben az már nem állt rendelkezésre. Szokásomhoz híven szeretek általános következtetést is levonni, ha lehet. És itt lehet. A probléma abból ered, hogy intuitíven a dátumra vagy időpontra úgy gondolunk, mint egy egyszerű érték, mint egy sima skaláris változó, egy integer vagy egy string. Viszont a dátumok összetett struktúrák, ld.: időzóna, szökőév, stb… Ezért aztán kódoláskor – nem tudatosan – azt feltételezzük, hogy érték szerint vannak átadva, nem pedig referencia szerint. Ez okozza a galibát, és pontosan ezt a viselkedést idézi elő a megváltoztathatatlan, azaz immutable viselkedés. Hozzáteszem, hogy a Chronos objektumok tudnak megváltoztathatóak lenni, csak kérni kell tőlük.

A másik csak kényelmi faktor, de szerintem szintén fontos, hogy lehet csak dátumokat kezelni. A Chronos csomag ad nekünk egy Date osztályt, aminek nincsen időpont komponense.

A harmadik ok szubjektív, amiért én anno a Chronos mellett döntöttem a Carbon ellenében. Belenéztem mindkettő kódjába, és az előbbi egyszerűen jobb minőségűnek, modernebbnek tűnt. Mint mondtam, ez szubjektív, de azért érdemes egy pillantást vetni a két kódbázisra, mielőtt elkötelezzük magunkat. Sőt, ha már használjuk a Carbon-t, akkor is, mert bizony nagyon könnyű áttérni. A Chronos ad egy segéd szkriptet is, amivel átírhatjuk a kódunkat automatikusan. Mondjuk én ezt nem próbáltam ki.

Telepítés

Ezen nincs mit cifrázni, így kell:

composer require cakephp/chronos

Példák a használatra

Néhány példa, ami nekem nagy segítség volt. További rengeteg példa emerre:

https://book.cakephp.org/3.0/en/chronos.html

A nap, hét, hónap, év utolsó másodperce:

$time = Chronos::now();
$time->endOfDay();
$time->endOfWeek();
$time->endOfMonth();
$time->endOfYear();

Következő péntek – ki ne lenne erre kícsi ?! :)

$time->next(ChronosInterface::FRIDAY);

Hétvége van már?

$now->isWeekend();

Különbség számítás:

$first->diffInHours($second);
$first->diffInDays($second);
$first->diffInWeeks($second);
$first->diffInYears($second);

Dátum formátumok:

$time->toRssString();
$time->toAtomString();
$time->toIso8601String();

Dokumentáció

Áttekintés, sok példával (fentieket is innen másoltam):
https://book.cakephp.org/3.0/en/chronos.html
API dokumentáció:
https://api.cakephp.org/chronos/1.0/

Összegzés

Én sokáig azt hittem, hogy semmi szükség ilyen csomagra, bőven elég amit a PHP ad. Aztán miután először használtam, be kellett látnom, hogy sokkal karbantarthatóbb és megbízhatóbb kódot lehet írni ezen csomagok használatával.

Örülnék, ha más is megosztaná a véleményét, használta-e valaki a Chronos-t vagy a Carbon-t.

MTA Sztaki: 1 év

Sztaki
drupal
php

Pontosan 1 évvel ezelőtt, 2013. április 22.-én kezdtem dolgozni az MTA Sztaki-ban. Magam sem gondoltam volna, hogy eddig húzom egy helyen :) De maradtam, mert jól érzem magam. Az elmúlt egy év sok különböző érdekes feladatot és számomra még ismeretlen technológiát tartogatott, így bőven volt kihívás és szakmai előrelépés is. Egyszóval mozgalmas év volt.

Jelenleg is keresünk tapasztalt vagy tanulni képes PHP és Java fejlesztőket, Drupal-os projekt is bőven. Részletekért Héder Michályt vagy Rigó Ernőt keressétek.

Magyar számok tól/től ragozása PHP nyelven.

php
magyar nyelv

Néhány másodpercig kerestem csak kedvenc keresőnkben, hogy létezik-e olyan PHP script amivel a magyar számokat lehet tól/től ragokkal ellátni, de nem találtam ilyet. A dolog pofon egyszerű, de mivel ilyen még nincs a neten (vagy én nem találtam) ezért gondoltam hasznos lehet. Pozitív és negatív egész számokra működik.

Update: 1.000.000 fölötti számokra nem jó, javítani fogom.

Update 2: Ha minden igaz akkor most már nagyon nagy számokra, 10^600-ig is jó. Forrás: wiki

<?php
function magyar_szam_tol_rag($szam) {
  $absz = abs($szam);
  
  switch ($absz % 10) {
    case 1:
    case 2:
    case 4:
    case 5:
    case 7:
    case 9:
      return "$szam-től";
    case 3:
    case 6:
    case 8:
      return "$szam-tól";
  }

  switch (($absz / 10) % 10) {
    case 1:
    case 4:
    case 5:
    case 7:
    case 9:
      return "$szam-től";
    case 2:
    case 3:
    case 6:
    case 8:
      return "$szam-tól";
  }
  
  if ($absz == 0) {
    return "$szam-tól";
  }
  elseif (1000 <= $absz && $absz < 1000000) {
    return "$szam-től";
  }
  else {
    return "$szam-tól";
  }
}
?>

Ha valahol hibás volna, jelezzétek a hozzászólásoknál.

PCRE találós kérdés

php
regex

Mutatok egy nagyon egyszerű reguláris kifejezést PHP-val:

<?php
  preg_match('|[\.-_]+|', $eml, $m);
?>

Szerintetek mire fog ez a minta illeszkedni? Annyit segítek, hogy nem a '.' a '-' és a '_' karakterekből sorozatokra illeszkedik.

Ha nem tudod, akkor lent adok egy kis segítséget.

Ez így már valóban a fenti 3 karaterből állós sorozatra illeszkedik:

<?php
  preg_match('|[-_\.]+|', $eml, $m);
?>

Ha ez sem segít, akkor van még egy utolsó segítségem.

Ez is csak a '.' a '-' és a '_' katekterekre illeszkedik:

<?php
  preg_match('|[\.\-_]+|', $eml, $m);
?>

A megfejtés, hogy az első verzióban a '.' és '_' karakterek közötti intervallumnak veszi a kifejezést, ezért egy csomó egyéb dologra is illeszkedni fog.