Niekedy sa dostaneme do situácie kedy Model potrebuje informáciu (typicky z http requestu) ale on sám o sebe nevie túto informáciu získať. To vedie k situácii kde si niektorí z nás “šáhnu” tam kde Model nemá čo hľadať!

Ako sa to stane?

K tomuto omylu dochádza vtedy, ako je vyššie spomenuté, ak Model potrebuje informáciu ktorú nevie sám získať.

Predstavme si situáciu kedy potrebujeme hodnotu $referral (na základe ktorého chceme napríklad zobraziť personalizovanú reklamu). Získanie tejto hodnoty je ale špecifické v tom, že:

• ak je používateľ prihlásený tak hodnotu $referral získame z databázy
• v prípade, že používateľ nie je prihlásený tak je uložená v COOKIE
• ak je daná COOKIE prázdna použijeme predvolenú hodnotu

Skúsme teda taký model nastreliť:

class AdGenerator {  const DEFAULT_REFERRAL = 'default';  /** @var string */
  private $referral;  public function __construct($referral) {
    $this->referral = $referral;
  }  public function generateRandomAd()…

Ako by to mohlo vyzerať keď sa nám nechce písať štýlom read-write model lebo ten zo sebou prináša kopu ďalších problémov a to projekt na ktorom pracujeme ešte nepotrebuje ale chceli by sme sa mu priblížiť.

Read-write model

O čom tento je model hovorí samotný názov. V skratke máme stranu ktorou dáta zapisujeme a stranu ktorou ich opäť čítame. V špecifikácii samotného CQRS je kopa ďalších cudzích slov ako “eventual consitency”, “projections”, … ktorými sa teraz zaoberať nebudeme.

Realita

Dobre to poznáme ako to na projekte po pár mesiacoch, rokoch vývoja za ktorým stojí X+1 ľudí vyzerá. A tzv. modely, ako to použitý framework nazýva, začnú robiť všetko. Dajme si malý príklad:

namespace Project\Models;class Users {  public function getById($id);
  public function getByEmail($email);
  public function countActivated();
  public function updateEmailById($id, $email);
  public function delete($id);
  public function deleteByEmail($email);
  // ďalších xy…

Alebo ako mať “rýchlejší” Docker na OSX-e

Na začiatok

V minulom príspevku sme preberali ako používať Docker na OSX tak, aby sme neboli obmedzovaní rýchlosťou resp. pomalosťou natívneho filesystému VirtualBoxu. Riešenie bolo v celku jednoduché a to prejsť z vboxfs na nfs. A celý proces zdieľania súborov medzi hostom a virtuálnym strojom sa rapidne zrýchlil. Jedným z hlavných dôvodov je nastavenie cache na strane virtuálu. No a presne cache je problém!

Prečo je cache problém?

Predstavme si situáciu, že pracujeme na projekte ktorý používa task runnery (Gulp, Grunt, …). A tu nastáva problém s cache-ovaním súborov vo virtuále. Čo presne sa deje a prečo sa to deje riešiť nebudeme. Dôležité je, že daný watcher nedetekuje zmenu okamžite. No ani nemá prečo lebo vo virtuále sa súbor nezmenil. …

Docker na OSX-e

Poslednou módou u nás v Rekurzii je, že na všetky projekty ktoré máme používame Docker. Nie však na serveri/och ale na vývojárskych mašinách. Dôvod je prostý. Každý máme iný notebook (Lenovo vs. Macbook). Tým pádom máme každý iný OS (operačný systém) a takisto nástroje ktoré pri vývoji používame. Čo však vďaka Docker-u máme spoločné je prostredie (OS na ktorom beží projekt a programy ktoré pre sú pre beh projektu potrebné). Niekto by mohol namietať, že z Docker-u takto vznikla konkurencia Vagrant-u. Nie je to úplne tak, no Vagrant schválne nepoužívame. Bol by to len ďalší overhead.

No a späť k Docker-u. Ono samotný Docker je výborná vec a určite je možné veľmi rýchlo nájsť tonu informácií aký je skvelý a prečo ho používať. Lenže tak ako tvrdia aký je super tak už málo z nich spomenie také maličkosti, že je primárne postavený na Linux! A ešte menej prizná, že na systémoch ako je Windows a OSX nefunguje. Ok, funguje ale nie tak ako by ste možno očakávali. Teraz predstavím jedno z možných riešení ako Docker prevádzkovať na OSX s tým aby jeho prednosti prevážili jeho nedostatky. …

Ako na testovanie pomocou Selenia v Docker kontaineroch

Selenium po starom

Testovanie pomocou Selenia klasickým spôsobom je vcelku jednoduchá záležitosť. Postup je v skratke nasledovný:

1. spustím Selenium server:

java -jar selenium-server-standalone-<version>.jar

Alternatívou je spustiť PhantomJS vo WebDriver móde:

phantomjs --webdriver '127.0.0.1:4444'

2. v konfigurácii testovacieho frameworku nastavím host a port serveru:

$host = 'http://localhost:4444/wd/hub';

prípadne len http://localhost:4444 ak použijem PhantomJS

3. a veselo testujem.

Selenium v Docker kontaineri

Ako prvé si vyberiem image ktorý budem používať pre beh Selenium serveru. Na Docker hube nájdem nejaké tie predpripravené image so Seleniom. Tieto image zväčša používajú jeden z prehliadačov ako je Firefox, Google Chrome prípadne Chromium.

Pre testovanie si ale vyberiem PhantomJS image s už spomínaným PhantomJS engine-om. Spustím ho príkazom:

$ docker run -d --name=phantomjs -p 8910:8910 wernight/phantomjs phantomjs --webdriver=8910

Mám spustený kontainer v ktorom beží PhantomJS v spomínanom WebDriver móde na porte 8910. Následne by som pustil kontainers s aplikáciou do ktorého by som nalinkoval tento kontainer. Čiže teraz možem kontainer s PhantomJS vypnúť a…

Ako si postaviť HTTP proxy v kontainer bez použitia — link

Život v izolácii

Ako dobre vieme Docker kontainery sú defaultne izolované od hosťovského stroja ale tak isto aj sami medzi sebou. V prípade, že ich potrebujeme spojiť je potrebné ich spolu tzv. “nalinkovať” pomocou prepínača — link.

$ docker run — name mysql -e MYSQL_ROOT_PASSWORD=root mysql$ docker run — link mysql:mysql nginx

Čo v prípade väčšieho počtu kontainerov a ich vzájomného linkovania začne byť nepohodlné.

$ docker run — name mysql -e MYSQL_ROOT_PASSWORD=root mysql $ docker run — name memcached memcached $ docker run — link mysql:mysql — link memcached:memcached nginx

Malá pomoc s docker-compose

S nástrojom docker-compose prichádza malá pomoc v podobe možnosti zapísania konfigurácie linkovania kontainerov do súboru docker-compose.y(a)ml, …