Ratchet – WebSockety w PHP w praktyce

WebSockety to jeden z najciekawszych od kilku lat tematów, z którymi przyszło mi zmierzyć się w pracy. Pierwszy raz słyszałem o nich gdzieś w 2013 roku i od tego czasu zdążyły zdobyć ogromną popularność w internecie. YouTube, Stack Overflow, Facebook – tam wszędzie WebSockety wykorzystywane są już od dawna do różnych rzeczy (przesyłanie i odświeżanie komentarzy oraz głosów, komunikacja w czasie rzeczywistym, itp.). To tyle słowem wstępu – jeżeli tu trafiłeś, prawdopodobnie wszystko to wiesz i szukasz informacji, jak wykorzystać WebSockety w praktyce.

Do zeszłego roku “WebSockety” i “node.js” stanowiły w zasadzie synonimy, jeżeli chodzi o ich implementację. O uruchomieniu ich w PHP czytałem same złe rzeczy i nawet najbardziej zagorzali programiści używający tego języka odradzali. Tematu jednak nie zgłębiałem i przyglądałem się nieco z boku. Jednak gdy w pracy pojawił się temat obsługi zdarzeń z centrali telefonicznej w naszym systemie, nie było wyjścia – trzeba zacząć się nimi szybko interesować.

Kolega z sąsiedniego zespołu już jakiś czas wcześniej podejmował ten temat w oparciu właśnie od node.js. Jego opinie nie były życzliwe, zwłaszcza, że nie miał wiele czasu na stworzenie tego rozwiązania. Podobnie z czasem było u mnie. Dodatkowo zniechęcał fakt, że w zasadzie nie mamy żadnej infrastruktury pod node.js, a ostatnią rzeczą, której bym chciał, to zarządzanie tym wszystkim od strony administracyjnej. Zacząłem więc szukać czegoś o WebSocketach w PHP.

Natychmiast trafiłem na Ratchet – bibliotekę do prostej implementacji WebSocketów w aplikacjach PHP. Brzmiało świetnie zwłaszcza, że mogłem korzystać z “dobrodziejstw” całego naszego systemu. W praktyce okazało się, że jest jeszcze lepiej i łatwiej, niż mi się wydawało.

Stwórzmy więc wspólnie skręcaną z drutów aplikację z pomocą Ratchet, która będzie niczym innym, jak prostym echotestem. Dodatkowo, oprócz odpowiadania na otrzymane wiadomości, serwer będzie sam wysyłał do wszystkich wiadomość, np. co 10 sekund. Dzięki temu otrzymasz bazę do większości zastosowań – nasza aplikacja będzie zarówno odpowiadała na komunikaty z inicjatywy klientów, jak i sama w pętli wysyłała coś od siebie.

Najpierw potrzebujemy samego Ratchet. Najłatwiej zlecić pobranie go composerowi. Jeżeli nie korzystałeś jeszcze z composera, spróbuj po prostu odwiedzić stronę pobierania i przejdź do sekcji “Manual download”, skąd możesz ściągnąć najnowszą wersję composer.phar. Umieść ten plik w katalogu głównym projektu, po czym możesz przejść do pobierania Ratcheta:

php composer.phar require cboden/ratchet

Kolejnym krokiem będzie stworzenie klasy obsługującej wszystkie potrzebne zdarzenia (połączenie, rozłączenie, wystąpienie błędu) oraz zawierającej metodę, którą serwer będzie cyklicznie wywoływać. Oto jej treść:

<?php
namespace WebSocket;
use Ratchet\MessageComponentInterface;
use Ratchet\ConnectionInterface;

class Handler implements MessageComponentInterface
{
    protected $clients;

    public function __construct()
    {
        $this->clients = new \SplObjectStorage;
    }

    public function onOpen(ConnectionInterface $conn)
    {
        $this->clients->attach($conn);

        echo 'Nowe połączenie: ' . $conn->resourceId . PHP_EOL;
    }

    public function onMessage(ConnectionInterface $from, $msg)
    {
        // iteracja po dostępnych połączeniach
        foreach ($this->clients as $client) {
            if ($from !== $client) {
                // bieżące połączenie to nadawca wiadomości
                
                // odsyłamy wiadomość
                $client->send($msg);
            }
        }
    }

    public function onClose(ConnectionInterface $conn)
    {
        $this->clients->detach($conn);

        echo 'Zamknięto połączenie: ' . $conn->resourceId . PHP_EOL;
    }

    public function onError(ConnectionInterface $conn, \Exception $e)
    {
        echo 'Wystąpił błąd: ' . $e->getMessage() . PHP_EOL;

        $conn->close();
    }
    
    public function onLoop($options = array())
    {
        foreach($this->clients as $client) {
            $client->send('Cykliczna wiadomość');
    
            echo 'Wysłano komunikat cykliczny' . PHP_EOL;
        }
    }
}

Klasę umieściłem w pliku handler.php.

Metody onOpen, onClose i onError są raczej oczywiste. W onMessage występuje obsługa zdarzenia pojawiającego się w momencie otrzymania wiadomości od klienta. Iterujemy tam po prostu po tablicy dostępnych połączeń i sprawdzamy, czy trafiliśmy na połączenie zgodne z identyfikatorem zasobu nadawcy. Jeżeli tak, to korzystamy z tego zasobu do odesłania odpowiedzi tej samej treści, którą otrzymaliśmy.

Metodę onLoop wykorzystamy natomiast do wywoływania cyklicznego. Wysyła ona do wszystkich połączeń komunikat o tej samej treści.

Mając taką klasę, możemy stworzyć plik, w którym uruchomimy sam serwer. W moim wypadku jest to server.php o następującej treści:

<?php
use Ratchet\Server\IoServer;
use Ratchet\Http\HttpServer;
use Ratchet\WebSocket\WsServer;
use WebSocket\Handler;

require 'vendor/autoload.php';
require 'handler.php';

// utworzenie obiektu klasy obsługującej
$handler = new Handler();

// stworzenie instancji serwera websocketów
$server = IoServer::factory(
    new HttpServer(
        new WsServer($handler)
    ),
    8080    // port
);

// ustawienie pętli
$server->loop->addPeriodicTimer(10, function() use ($server, $handler) {
    // uruchomienie metody obrotu pętli
    $handler->onLoop(array(
        'server' => $server,
    ));
});

echo 'Serwer uruchomiony' . PHP_EOL;

// uruchomienie serwera
$server->run();

Jak widać, tworzymy najpierw instancję serwera nasłuchującego na porcie 8080, podając mu klasę z obsłużonymi zdarzeniami, a następnie dodajemy pętlę, która będzie wywoływana co 10 sekund.

Teraz wystarczy uruchomić serwer poprzez wywołanie:

php server.php

W konsoli powinniśmy dostawać informacje o przebiegu działania serwera.

Jak się połączyć z naszym serwerem? Najprościej uruchamiając konsolę w przeglądarce (w Firefoksie możemy wywołać ją kombinacją CTRL-SHIFT-K) i wklejając:

var conn = new WebSocket('ws://localhost:8080');
conn.onopen = function(e) {
    console.log("Połączono pomyślnie!");
};

conn.onmessage = function(e) {
    console.log(e.data);
};

Po chwili powinniśmy otrzymywać z serwera co 10 sekund wiadomość.

Aby wysłać wiadomość do serwera, wystarczy, że w tej samej konsoli wkleimy:

conn.send('Test');

To wszystko! Mamy już działający serwer.

Oczywiście, docelowa aplikacja musi zawierać obsługę uwierzytelniania, jednak celem tego wpisu było pokazanie prostoty stworzenia serwera WebSocketów.

Wpis był mocno inspirowany oficjalnym tutorialem Ratcheta, który rozbudowałem o cykliczne wywoływanie zdarzeń przez serwer.

Optymalizacja zapytań z GROUP BY w MySQL (i nie tylko)

Przyznam, że do wczoraj sposób działania planera w przypadku zapytań agregujących (z klauzulą GROUP BY) był dla mnie nie do końca jasny.

Akurat trafiłem w mojej aplikacji na zapytanie na tyle proste, a jednocześnie wolne (operujące na dużej tabeli), że łatwo było je analizować. Szukając przyczyny i sposobów optymalizacji, trafiłem na znakomitą odpowiedź na stackoverflow. Pozwolę sobie wkleić jej sedno:

For covering index you add:
1. columns used in where clauses first, then
2. columns used in group by, then
3. columns used in order by, and then
4. columns used in select.

Ze swoim zapytaniem miałem nieco większy problem, ponieważ łączyło ono dwie tabele poprzez JOIN. Jak się okazuje, kolumny z warunków JOIN-owania należy przypisać do pierwszego punktu, co potwierdziło się w moim dzisiejszym pytaniu.

Sprawdziłem działanie tego schematu również na zapytaniach z GROUP BY na dużych tabelach w PostgreSQL i również działało (skutkowało wykonywaniem zapytania w pełni na indeksach), więc można przyjąć, że podobnie działa to dla większości popularnych DBMS.

YouTube – access forbidden, the request may not be properly authorized

Jeżeli ostatnio trafiłeś na tytułowy błąd, a dokładniej:

HTTP 403: youtube.common, Access forbidden. The request may not be properly authorized.

w swojej aplikacji sprzężonej z YouTube poprzez API, to wiedz, że aplikacja działa w pełni poprawnie. Nie szukaj też przyczyny w tokenach autoryzacyjnych.

Przyczyna jest zupełnie inna – Google wprowadził w API YouTube’a zabezpieczenie przed spamem (a raczej floodem). W związku z tym w ciągu jednej doby można przesłać bez ograniczeń do 50 nagrań, potem API będzie blokowało przesyłanie większej liczby nagrań niż jedno na 15 minut. Każdy nadmiarowe będzie wyrzucało właśnie zacytowany wyżej błąd.

Zmiany zostały podobno wprowadzone 24 lutego 2017. Sam trafiłem na to ograniczenie następnego dnia. Podobnych wzmianek jest już w sieci jednak sporo, np. #1, #2, #3, #4, #5, #6, #7, #8. Trochę współczuję ludziom, którzy oparli w swoich aplikacjach magazynowanie dużej ilości multimediów na YouTube.

PostgreSQL – losowe wartości z podzapytania

W PostgreSQL, korzystając z podzapytania używającego funkcji RANDOM() tak, jak np. w MySQL, otrzymamy te same wyniki dla każdego wiersza.

Przykład:

SELECT
    t1.id,
    (SELECT name FROM table2 ORDER BY RANDOM() LIMIT 1) AS random_name
FROM table1 t1

W tym DBMS podzapytanie tego typu wykonuje się raz, więc przy każdym wierszu z tabeli table1 będzie widniała ta sama wartość random_name.

Aby to zmienić, wystarczy sztucznie skorelować podzapytanie z zapytaniem nadrzędnym, np. tak:

SELECT
    t1.id,
    (SELECT name FROM table2 WHERE t1.id = t1.id ORDER BY RANDOM() LIMIT 1) AS random_name
FROM table1 t1

Niby proste, ale jakiś czas temu straciliśmy w pracy na tym trochę czasu (zwłaszcza nie wiedząc, że problem jest związany z podzapytaniami, bo samo zapytanie było bardziej złożone).

Eclipse – ponowne wywołanie informacji kontekstowej

Gdy w Eclipsie wywołujemy metodę/funkcję, pojawia się informacja kontekstowa z listą jej parametrów wraz z wyróżnieniem właśnie wpisywanego:

Gdy jednak wciśniemy escape lub utracimy focus na metodzie, informacja ta nie pojawia się ponownie, co zawsze było dla mnie problemem (trzeba było najechać na nazwę metody/funkcji, aby uzyskać informację o parametrach). Okazuje się jednak, że aby ponownie wywołać tę podpowiedź wystarczy wcisnąć CTRL+SHIFT+spacja.

Źródła: [1], [2]

Automatyczne generowanie opisu commita przy git merge

Krótko, lecz treściwie: odkryłem przełącznik --log=n  przy git merge.

Będąc na feature branchu opisuję dokładnie zmiany wraz ze znacznikami zagadnienia, co potem jest przetwarzane Redmine’a. Niestety, przy wykonywaniu merge’a do mastera sugerowana jest domyślna treść, którą nadpisywałem skopiowanym opisem któregoś z ostatnich commitów w branchu.

Aż do wczoraj. Kolejny raz przeczytałem manual i doszukałem się w nim ww. przełącznika. W moim przypadku wystarczy więc wykonać merge’a poprzez:

git merge --log=n redmine-XXXXX

Dzięki temu do domyślnej treści merge’owego commita dopisywana jest lista opisów ostatnich n commitów z tego brancha.

3-way merge przy aplikowaniu patcha w git

Nigdy nie rozumiałem sensu używania git apply. Kiedyś zastanawiałem się, czy ma jakieś zalety w stosunku do sprawdzonego patcha. Przejrzałem wtedy nawet pobieżnie manuala stwierdzając, że jest tam przecież tylko to, co ma sam patch. W swojej pracy używałem więc sprawdzonego i dobrze znanego patcha.

Dopiero niedawno uświadomiłem sobie, że pominąłem chyba najistotniejszy przełącznik: -3 . Jego użycie powoduje (w przypadku, gdy diff nie aplikuje się wprost) wykonanie 3-way merge’a. W wielu przypadkach samoczynnie rozwiązuje to problem z aplikowaniem diffów, których nie dałoby się zastosować przy użyciu samego patcha.

Firefox – narzędzia dla programistów zamiast Firebuga

Dopiero niedawno dowiedziałem się, że popularny dodatek do Firefoksa – Firebug – jest już od jakiegoś czasu martwy. Autorzy zalecają używanie narzędzi dla programistów wbudowanych w Firefoksa.

Mając świadomość, że z czasem pojawią się problemy (a jeden wystąpił już kilka miesięcy temu, gdy chciałem podejrzeć ruch generowany przez websockety), usunąłem Firebuga i zacząłem korzystać z wbudowanych narzędzi. Jak na przesiadkę z narzędzia, którego używam co najmniej od 5 lat, proces przebiegł zaskakująco łatwo.

Wbudowane narzędzia dla programistów na pierwszy rzut oka są według mnie nieco ładniejsze od Firebuga. Inspektor oraz wyróżnianie nim elementów jest czytelniejsze. Edycja drzewa DOM jest łatwiejsza, zaś zdarzenia JS (które w Firebugu były dość mocno zakamuflowane)  są teraz oznaczone tagiem “ev” przy elemencie, pod który są podpięte.

Na uwagę zasługuje też narzędzie do badania wydajności oraz przebudowany panel “Sieć”, który wyświetla szczegóły żądań w wygodniejszy sposób. Prezentuje on też dane przesyłane przez websockety, czego brakowało Firebugowi.

Narzędzia dla programistów z Firefoksa posiadają też kilka nowych funkcji. Mnie w oczy rzucił się “Brudnopis” otwierany w osobnym oknie (a nie jako część panelu konsoli) oraz wygodny “Próbnik koloru”, automatycznie kopiujący do schowka kod koloru wskazanego piksela. Nie może tu zabraknąć też narzędzia: “Widok trybu responsywnego”, który ułatwia rozwijanie aplikacji z responsywnym layoutem.

Podsumowując – polecam. Przesiadka jest praktycznie bezbolesna, a warto choćby ze względu na wymienione wyżej nowości i usprawnienia.

 

Bitcoin nie daje rady

Bitcoin to niewątpliwie waluta przyszłości. Prostota użycia, implementacji, anonimowość i błyskawiczne płatności, a to wszystko niezależnie od rządów i – przy stosowaniu się do kilku reguł – podatków. Właśnie tak myślałem, dopóki nie przyszło mi skorzystać z tej waluty w praktyce. Całe szczęście, że nie do końca do moich celów.

Bitcoin stał się popularny w polskich mediach w zeszłym roku, pewnie ze względu na gwałtownie rosnący kurs BTC do USD (jednak ta bańka pękła prawdopodobnie na początku grudnia). To spowodowało, że zainteresowałem się tematem i postanowiłem przetestować, jak płatności Bitcoin sprawdzają się w praktyce.

I żeby nie przedłużać – nie sprawdzają się. Spostrzeżeń jest kilka:

  1. Bitcoin nie nadaje się do mikropłatności. Jeżeli masz serwis oferujący relatywnie tanie usługi i chcesz wdrożyć płatności w tej walucie, szybko o tym zapomnij – unikniesz wyrzucenia pieniędzy w błoto. Małe transakcje są znaczącym problemem dla sieci i są przez osoby z nią związane wprost nazywane spamem. W efekcie oficjalny klient, dla transakcji niskopriorytetowych – wymusza minimalną opłatę transakcyjną na poziomie 0,0001 BTC, czyli ok. 0,26 zł w dniu i godzinie redagowania tego wpisu. W praktyce jednak opłata ta jest wyższa. Przykładowo – przy wykonaniu pojedynczej, testowej płatności pomiędzy swoimi portfelami na kwotę 0.00006 BTC (~0,16 zł) zapłaciłem 0.00146 BTC (~0,38 zł) prowizji. Słabym pocieszeniem jest brak faktycznej konieczności płacenia prowizji od transakcji powyżej 0,01 BTC (~26 zł). W pozostałych przypadkach, jeżeli nie zapłacisz prowizji, zapomnij o potwierdzeniach transakcji w rozsądnym czasie. Lepiej skorzystaj z ELIXIR.
  2. Zerowa wiarygodność kursu. O ile punkt pierwszy Cię nie dotyczy, przygotuj się na konieczność szybkiego i częstego “przewalutowania” płatności otrzymanych w Bitcoin na coś stabilniejszego, lub na ryzyko utraty sporego odsetku pieniędzy w ciągu długiego weekendu. Zdaję sobie sprawę, że jest to pewnie kwestia młodego wieku tej waluty, jednak niedogodność tę trzeba mieć “z tyłu głowy” przy podejmowaniu decyzji o wdrożeniu płatności w Bitcoinach.
  3. Anonimowość w płatnościach Bitcoin to fikcja. Wszystkie transakcje są dostępne publicznie. Co z tego, że do informacji należy tylko adres portfela źródłowego, docelowego i kwota i że nie ma tam żadnych danych stron transakcji, tytułów, itp.? W praktyce jednak zawsze dojdzie do powiązania adresu portfela z podmiotem gospodarczym. A do tego wystarczy już tylko Google i np. https://blockchain.info/, i już każdy zna nie tylko saldo Twojego portfela, ale też szczegóły wszystkich jego transakcji. Jeżeli chcesz w miarę szybko zacząć przygodę z Bitcoin, prawdopodobnie kupisz pierwsze Bitcoiny w którymś z dużych kantorów. Przyda Ci się więc informacja, że jeden z największych – https://www.mtgox.com/ – przy rejestracji może poprosić Cię nie tylko o skan dokumentu tożsamości, ale też np. wystawionego na Ciebie rachunku za bieżące opłaty.

Powyższe powody dyskwalifikują dla mnie BTC w obecnym czasie. A szkoda, bo zakochałem się w tym, jak proste jest korzystanie z tej waluty – zarówno w zwykłych transakcjach, jak i samym wdrożeniu płatności w tej walucie w aplikacjach internetowych.

Chyba znalazłem swoją następną dystrybucję Linuksa

UWAGA! Ten wpis ma już 6 lat. Pewne stwierdzenia i poglądy w nim zawarte mogą być nieaktualne.

Od ładnych paru lat korzystam z Mandrivy. Wersja 2007.1 była chyba szczytem formy tej dystrybucji. Korzystałem z niej krótko mimo tego, że nie było z nią większych problemów. Cały sprzęt w moim Acerze był obsługiwany out of the box, nawet tak egzotyczne rzeczy, jak klawisze walutowe czy port IrDA. Diabeł tkwił jednak w szczegółach – Mandriva 2007.1 posiadała kilka drobnych, jednak irytujących błędów. Jednym z nich była totalna zwiecha systemu przy odłączaniu z USB niektórych urządzeń, np. drukarki. Utrudniało to mobilność – chęć przeniesienia laptopa w inne miejsce musiała zostać zabita w zarodku, gdy podłączona była drukarka. Wtedy jednak jakoś sobie z tym radziłem, do czasu, gdy wyszła wersja 2008.0, a potem – 2008.1.

Ta ostatnia na dobre zawitała na moim dysku – instalacja z 2009 roku działa do dziś i to właśnie na niej cały czas pracuję. Jednak od tej wersji następował upadek tej dystrybucji. I nie chodziło jeszcze wtedy o głupie decyzje developerów. Najbardziej widoczne było to w liczbie bugów, które przelewały się przez mandrivowe fora. Wiele z nich dotyczyło również mnie, a konkretniej – mojego sprzętu.

Permanentnie przestało działać wiele rzeczy, zaś niektóre wymagały długiego grzebania w systemie, aby osiągnąć efekt z wersji poprzedniej. Przestało działać sterowanie podświetlaniem z klawiatury, przez co musiałem napisać prosty skrypt korzystający z xbacklighta. Były problemy z WiFi, które zostały częściowo rozwiązane, jednak do tej pory mam problem z łączeniem się z lepiej zabezpieczonymi sieciami. IrDA nie działa, jednak nie poświęcałem jej wiele czasu, bo nie była mi już potrzebna tak, jak wcześniej. Z Bluetooth nie da się zrobić nic poza wyszukiwaniem urządzeń. I chyba najbardziej uciążliwa usterka – przestał działać suspend2ram, przez co byłem skazany co najwyżej na hibernację.

Co rok sprawdzałem kolejne wersje Mandrivy. Było jednak tylko gorzej – z każdą wersją działało coraz mniej. Chciałem to jednak naprawić, bo wersja 2008.1 starzała się coraz szybciej, znikały też kolejne serwery hostujące repozytoria z paczkami RPM. Ściągnąłem i zainstalowałem wersję cooker z nastawieniem na zgłaszanie bugów, które najbardziej mi przeszkadzają. Jak głupi byłem, okazało się dopiero po paru tygodniach.

Developerzy Mandrivy obrali postęp za główną ideę przy tworzeniu systemu. I o ile nie mam nic przeciwko temu, o tyle oni uparcie brnęli w rozwiązania bezsensowne. W 2009.1 nie było już KDE3.5 – został on zastąpiony wczesną wersją KDE4. W ten sposób otworzono puszkę pandory.

Każdy, kto miał do czynienia z KDE4 w jego pierwszych wersjach wie, jak fatalne było to środowisko. Niestabilność i restarty były powszechne. Jednak z jakiegoś powodu, developerzy Mandrivy umieścili to środowisko jako wiodące w 2009.1, jednocześnie pozbawiając KDE3.5 w repozytoriach kluczowych do jego działania paczek. Czarę goryczy przelało także PulseAudio i pomysł na przepisanie wszystkich aplikacji z KDE3.5. Dzięki temu otrzymaliśmy Amaroka 2, paskudnego jak noc “iTunes wannabe” bez tak kluczowych opcji, jak powtarzanie utworu, losowanie czy korektor graficzny. Mimo, że 2009.1 była dla mnie nieużywalna, dodawałem na potęgę bugi w Bugzilli Mandrivy. Bez skutku – większość błędów pozostała, niektóre po prostu zostały olane mimo, że problem nie zniknął.

Po tym wydarzeniu okopałem się w wersji, z której korzystałem – 2008.1. Zrobiłem sobie mirror repozytorium na płytach DVD na wszelki wypadek. I korzystam z niej do dzisiaj.

Jednak parę dni temu zainteresowałem się znowu najnowszą wersją Mandrivy. Rozczarowałem się – 2011 jest tak samo beznadziejna. Czytałem tez na temat zawirowań ws. tej dystrybucji i kolejnych przetasowaniach. Jeszcze pod koniec poprzedniego roku obiecywano “odrodzenie” Mandrivy i wydanie wersji 2012 w marcu. Tak, marzec minął, a oficjalne wiki dystrybucji milczy. Jestem prawie pewien, że Mandriva już umarła.

W internecie pojawiały się jednak przebąkiwania o forku Mandrivy o nazwie Mageia. Z nudów postanowiłem ściągnąć LiveCD pierwszej wersji.

Do tej pory nie mogę wyjść z zachwytu. KDE jest używalne, jest Clementine zamiast Amaroka 2. WSZYSTKO działa tak, jak w Mandrivie 2007.1, a nawet lepiej. WiFi poprosiło tylko o ścieżkę do firmware, i zaczęło sygnalizować swoją obecność diodą na obudowie, która nie świeciła od paru ładnych lat, sterowanie podświetleniem działa, IrDA się odzywa, bluetooth działa natychmiast po wtyknięciu adaptera na USB. Działa też suspend2ram. I to wszystko od razu po uruchomieniu systemu z LiveCD.

Zacząłem śledzić rozwój Magei, jako, że za miesiąc ma wyjść druga jej wersja. I jeżeli będzie tak dobra, jak poprzednia, to na pewno na długo u mnie zagości. O ile oczywiście nie wezmą przykładu ze swojego pierwowzoru. :>