Czy scrum rujnuje świetnych inżynierów, czy robisz to źle?

Na blogu stackoverflow trafiłem ostatnio na tytułowy wpis: Does scrum ruin great engineers or are you doing it wrong? Traktuje głównie o scrumie, ale jego większość dotyczy ogólniejszych problemów zarządzania projektami i zespołami. Dawno nie czytałem czegoś tak celnego i przystępnego, toteż polecam i wrzucam na blog, żebym sam o nim nie zapomniał.

Traits w PHP

Traits w PHP są obecne już od wersji 5.4, więc od dość długiego czasu (2012). Sam pierwszy raz czytałem o nich parę lat później, jednak nie wydały mi się atrakcyjne – są próbą wypełnienia braku dziedziczenia wielokrotnego, które nigdy w praktyce mi się nie przydawało jeszcze w czasach C++, a rodziło problemy, które komplikowały czasem bardziej niż jego brak. Zapomniałem więc o traits na wiele lat, nie widziałem też w tym czasie dla nich zastosowania (podobnie, jak wyparłem kiedyś dziedziczenie wielobazowe).

Aż do zeszłego roku. Trafiłem wtedy na zagadnienie, w którym przydatne byłoby wykorzystanie tego samego kodu w trzech zupełnie różnych klasach, z których każda miała już swoją dość złożoną strukturę i odpadało stworzenie klasy nadrzędnej, po której dziedziczyłyby wszystkie z nich.

Można było niby skorzystać z klasy helpera i pobierać jego instancję lub wstrzykiwać, jednak to też wprowadzało pewien nieład zwłaszcza, że jedna z tych klas modyfikowała działanie części kodu, którą potrzebowałem “uwspólnić”.

Nie było więc innego wyjścia, niż zainteresować się traitsami. I był to strzał w dziesiątkę. Traitsy to tak naprawdę kawałki kodu do wielokrotnego użytku. Wyglądają jak klasy, jednak nie wprowadzają zmian w strukturze typów. Nie narzucają też praktycznie niczego – używane w nich pola i metody nie muszą istnieć w nich samych, jeżeli wprowadzają konflikty, to można je łatwo rozwiązać. Nie można utworzyć ich samodzielnych instancji. Teoretycznie blisko jest im więc do klas abstrakcyjnych, z tą różnicą, że w PHP możemy dziedziczyć tylko jednej klasie abstrakcyjnej, natomiast traitstów możemy użyć tyle, ile potrzebujemy.

Korzystanie z nich jest więc podobne do skopiowania ich treści do bieżącej klasy. Dodatkowo, możemy aliasować poszczególne traitsy, a także metody z nich tak, aby nie zachodziły konflikty z już istniejącymi metodami, do których zaciągamy trait. Metody zaciągane z traits mogą być nadpisywane lokalnie, działa to wtedy tak, jak byśmy nadpisywali metodę z klasy nadrzędnej. Nadal można przy tym korzystać z nadpisywanej metody z trait.

Jeżeli chodzi o wady, to należy pamiętać o konfliktach w przypadku współistnienia pól.

Przyznam, że od czasu pierwszego użycia, pomijając początkowo neoficką fascynację, zacząłem widzieć coraz więcej obszarów, w których mógłbym stosować traitsy, i coraz częściej pojawiają się one w moim kodzie.

Trigger ON UPDATE i ON DELETE na spartycjonowanej tabeli w PostgreSQL

Kolejna ciekawostka, na którą się naciąłem ostatnio w pracy. Otóż w przypadku spartycjonowanej tabeli, triggery ON UPDATE i ON DELETE są wykonywane jedynie na tabeli potomnej zawierającej dane wiersza określonego przez warunki w WHERE (o ile oczywiście istnieją).

Oznacza to, że w przypadku partycjonowania tabel na podstawie np. wartości klucza głównego poprzez ograniczenie CHECK, planner najpierw spróbuje wyznaczyć partycje zawierające wiersz(e) spełniające warunki zapytania, a następnie wywoła triggery ON UPDATE/ON DELETE jedynie na tabelach zawierających dane do usunięcia/aktualizacji.

Jest to zachowanie inne niż w przypadku ON INSERT, gdzie trigger wywoływany jest bezpośrednio na tabeli, na której wywołano instrukcje INSERT mimo, że sam trigger ON INSERT na niej może delegować operacje wstawienia do innych tabel potomnych.

Profilowanie aplikacji w PHP

Krótko i na temat, bo pierwszy raz zacząłem korzystać z profilowania aplikacji w PHP dawno temu, a często przydaje mi się odświeżenie informacji na ten temat.

Po instalacji xdebug wystarczy dodać do .htaccess:

php_value xdebug.profiler_enable 1
php_value xdebug.profiler_output_dir /output/path/
php_value xdebug.profiler_output_name cachegrind.out.%t-%s
php_value xdebug.profiler_enable_trigger 1

Następnie wczytujemy w przeglądarce żądaną stronę (z włączonym profilerem może trwać to nawet kilkanaście razy dłużej), aby we wskazanym wyżej katalogu uzyskać logi profilera. Logi te można wczytać za pomocą np. KCacheGrind (dostępny zarówno pod Linuksem, jak i Windowsem).

W KCacheGrind po podpięciu kodu źródłowego otrzymujemy listę wywołań z kosztem czasowym każdego z nich. Dzięki temu łatwo wyłapać najbardziej czasochłonne części kodu.

Widoczność pól i metod innych obiektów tego samego typu w PHP

Ostatnio, refaktoryzując kod, dowiedziałem się o pewnej ciekawej właściwości PHP. Otóż obiekty tych samych typów mają dostęp do prywatnych i chronionych metod oraz pól nawet, jeżeli stanowią oddzielne instancje tej samej klasy. Początkowo myślałem, że to jakiś błąd w kodzie, który analizowałem, jednak znalazłem potwierdzenie w manualu PHP:

Objects of the same type will have access to each others private and protected members even though they are not the same instances. This is because the implementation specific details are already known when inside those objects.

http://php.net/manual/en/language.oop5.visibility.php#language.oop5.visibility-other-objects

Co ciekawsze, w innych popularnych językach jest podobnie, więc nie jest to swoistość samego PHP, na co nigdy nie zwróciłem uwagi…

NOW() przy zapytaniach na spartycjonowanych tabelach

Ostatnio dowiedziałem się, że funkcje NOW() oraz CURRENT_TIMESTAMP w PostgreSQL nie są immutable, co powoduje, że wyrażenia z tymi funkcjami nie pomogą w optymalizacji zapytań na spartycjonowanych tabelach, których klauzule CHECK dotyczą przedziałów czasowych. Wartości tych funkcji nie są znane planerowi w momencie wykonywania zapytania:

Constraint exclusion only works when the query’s WHERE clause contains constants (or externally supplied parameters). For example, a comparison against a non-immutable function such as CURRENT_TIMESTAMP cannot be optimized, since the planner cannot know which partition the function value might fall into at run time.

https://www.postgresql.org/docs/10/ddl-partitioning.html

Aby zapytanie korzystało jedynie z właściwych partycji, należy więc przekazywać daty/przedziały czasowe jako stałe (np. pobierając je z poziomu języka programowania aplikacji korzystającej z bazy danych) lub z innych tabel. W niektórych rozwiązaniach można po prostu stworzyć tabelę z jednym wpisem i kolumną typu date, której wartość będzie codziennie aktualizowana (nadal jednak utracimy możliwość wyszukiwania uwzględniającego godzinę).

Kolejność w zapytaniu z DISTINCT ON

Na problem z nieustawioną kolejnością w zapytaniu zawierającym DISTINCT ON natknąłem się już jakiś czas temu, jednak dopiero teraz zebrałem się, aby go opisać. A warto, bo niby błahy, a jednak ciekawy i sam trochę ignorowałem jego znaczenie.

Otóż korzystając w zapytaniu z DISTINCT ON na zestawie kolumn powinniśmy ustawić kolejność prezentacji wierszy poprzez standardową klauzulę ORDER BY. DISTINCT ON pomija bowiem kolejne wiersze o wartościach, które wystąpiły już wcześniej:

DISTINCT ON ( expression [, …] ) keeps only the first row of each set of rows where the given expressions evaluate to equal. […] Note that the “first row” of each set is unpredictable unless ORDER BY is used to ensure that the desired row appears first. […] The DISTINCT ON expression(s) must match the leftmost ORDER BY expression(s).

http://www.postgresql.org/docs/9.0/static/sql-select.html#SQL-DISTINCT

Bez ustawionej kolejności może być przypadkowa (chodź technicznie to nie do końca prawda) i różna w zależności od sposobu użycia.

Przykład? Opiszę mój przypadek w nieco zmodyfikowanej formie. Miałem zapytanie korzystające z dwóch tabel: pierwsza to tabela z numerami telefonów klientów wraz z etykietami. Jeden klient może posiadać kilka telefonów, nawet z tymi samymi etykietami (ze względu na przypisywanie tych numerów do jego umów, których może być wiele):

id_customer
id_contractnumberlabel
512
600123123
Company Ltd.
513600123123Company Ltd.
514600123123John Poe

Z tabeli pobierane były unikalne numery telefonów dla klienta wraz z pierwszą etykietą – ta bowiem nie była do końca ważna. Korzystałem więc z zapytania:

SELECT DISTINCT ON (id_customer, number)
    id_customer,
    number,
    label
FROM customers

Nakładając na zapytanie ograniczenie na ID żądanego klienta otrzymywałem wiersze z jego telefonami oraz etykietą. Jeżeli do jednego numeru klienta było kilka etykiet, mogła zostać zaprezentowana dowolna z nich, każda bowiem była prawidłowa i w tym zastosowaniu nie miało to znaczenia.

Trzeba było jednak rozszerzyć tabelę o dodatkowe dane (tagi), które nie występowały – jak etykiety – przy każdym wierszu klienta. Jeżeli już jednak istniały, należało je zaprezentować, a jeżeli było ich kilka – najważniejszą z nich według zadanego priorytetu. Pominę przy analizie priorytet, ponieważ nie jest on aż tak istotny. Tabela po zmianach wyglądała więc tak:

id_customer
id_contractnumberlabeltag
512
600123123
Company Ltd.
urgent
513600123123Company Ltd.
514600123123John Poe

Do zapytania dodałem tylko kolumnę z interesującą mnie daną:

SELECT DISTINCT ON (id_customer, number)
    id_customer,
    number,
    label,
    tag
FROM customers

Przy testach wszystko było OK, zawsze zwracane były wiersze z wypełnioną kolumną tag. To nieco uśpiło moją czujność i nie przetestowałem takiej liczb przypadków, abym trafił na pustą wartość mimo istnienia tagu dla numeru.

Sytuacja zmieniła się, gdy zapytanie trafiło do SQL-owego widoku. To zmieniło sposób sortowania wyników, przez co pobierając dane z widoku miałem przypadki zwracania numerów bez tagów mimo, że te ewidentnie istniały. Żeby było zabawniej, wykonanie zapytania bezpośrednio (z pominięciem widoku) działało tak, jak bym chciał.

Wróciłem więc do dokumentacji i stackoverflow. To naprowadziło mnie na podany na początku wpisu fragment dokumentacji. Aby poprawić zapytanie, należało więc użyć ORDER BY:

SELECT DISTINCT ON (id_customer, number)
    id_customer,
    number,
    label,
    tag
FROM customers
ORDER BY tag NULLS LAST

Dzięki temu, wiersze z tagami były zwracane jako pierwsze i ewentualne późniejsze wiersze z pustymi wartościami w tej kolumnie dla tego samego klienta i numeru były pomijane, a nie odwrotnie.

Nie można więc zapominać o klauzuli ORDER BY po kolumnach niewystępujących w DISTINCT ON, bo prędzej czy później się to zemści.

Chrome dla Androida – zdalne debugowanie aplikacji webowej

Dostosowujemy ostatnio aplikację webową do urządzeń mobilnych. Pierwszym pytaniem, które mi się nasunęło, było: “czy przeglądarki mobilne mają w ogóle wbudowane narzędzia deweloperskie?”. Odpowiedź w uproszczeniu brzmi: nie. W tym sensie, że nie uruchomimy tych narzędzi bezpośrednio na urządzeniu, co zresztą byłoby dość kłopotliwe ze względu na ich złożoność.

Krótkie przeszukiwanie internetu naprowadziło mnie na informacje o zdalnym debugowaniu. Brzmiało zbyt pięknie, aby było możliwe bez większego wysiłku. Pracuję na Linuksie, więc już sobie wyobrażałem rozwiązywanie problemów z połączeniem. Postanowiłem jednak przebić się przez ten krótki opis. Efekty były zaskakujące.

Okazało się, że w zasadzie wszystko działa out of the box. Po stronie komputera nie wymagało w zasadzie żadnej konfiguracji – urządzenie było widoczne od razu na liście. Zmian wymagały jedynie ustawienia na telefonie/tablecie.

Ale po kolei: na początku musimy włączyć debugowanie USB w opcjach programisty. W moim telefonie ze starszym Androidem 4.1.2 opcje programisty dostępne są bezpośrednio z ustawień:

Na nowszych należy je uaktywnić poprzez siedmiokrotne stuknięcie w “Build number” (zgodnie z opisem).

Po włączeniu debugowania USB, wystarczy podłączyć urządzenie kablem USB do komputera oraz włączyć Chrome na obu urządzeniach. Na komputerze wystarczy teraz włączyć narzędzia dla programistów (CTRL+SHIFT+I) i z menu wybrać: More tools -> Remote devices:

Na liście powinniśmy zobaczyć podłączone urządzenie. Po kliknięciu możemy wpisać adres do otwarcia na nim w nowej karcie lub debugować którąś z już otwartych kart na urządzeniu mobilnym poprzez kliknięcie na: “Inspect” przy jej nazwie. Pojawi się wtedy nowe okno z podglądem widoku strony na urządzeniu mobilnym oraz panel z narzędziami developerskimi. Zmiany wykonane na urządzeniu widoczne są w podglądzie na komputerze i vice versa:

Z takimi możliwościami rozwijanie aplikacji webowych na urządzenia mobilne to czysta przyjemność. 🙂

PSR-1 i PSR-2

Tym razem krótko, bo chciałem tylko zaznaczyć istnienie PSR-1 i PSR-2. Cieszę się, że te dwa zalecenia powstały i że modne jest stosowanie się do nich, przez co istnieje duże prawdopodobieństwo, że przeglądając źródła zarówno swojego projektu, jak i innych, dostępnych publicznie, a często używanych, trafimy na czytelne i zbieżne formatowanie. Sam musiałem wyplenić kilka złych nawyków, ale dzięki kod jest dużo czytelniejszy.

Wojny edycyjne uznajemy więc za zakończone. 😉

Moje webdevowe lektury

Pracując na co dzień z systemami stworzonymi ładnych parę lat temu, a jednocześnie zbyt złożonymi, aby je co jakiś czas przepisywać w całości, nietrudno wypaść z obiegu. Wprawdzie nasz biznes nie narzeka na brak pomysłów, dzięki czemu co jakiś czas musimy korzystać z czegoś zupełnie nowego (jak opisywane przeze mnie jakiś czas temu websockety), jednak i tak następuje to zbyt rzadko, by nie zardzewieć bez douczania się na własną rękę.

Co czytam?

Książki

Tych nie było wiele, ale gdy już były, to okazywały się strzałem w dziesiątkę. Książki, które opiszę, były kamieniami milowymi w moim rozwoju, a miałem to szczęście, że sięgnąłem po nie w momentach, w których mogłem się mocno zaangażować w ich lekturę.

Pierwsza z nich to: Wzorce projektowe. Rusz głową! (Elisabeth Freeman, Eric Freeman, Bert Bates, Kathy Sierra). Długo myślałem nad zakupem tej książki. Z jednej strony wiedziałem na pewno, że potrzebuję gruntownej wiedzy o wzorcach projektowych. Był to okres, gdy zorientowałem się, że wiele osób w moim otoczeniu sprawnie nimi operuje w rozwiązywaniu realnych problemów i jednocześnie gdy frustrowałem się tym, że moja wiedza w tym temacie jest na tyle ogólnikowa, że nie rozumiem artykułów o wybranych wzorcach na wikipedii. Z drugiej strony, część osób przestrzegało przed tą książką jako przeładowaną obrazkami. Nie pomagał fakt, że była ona wtedy dość droga. Ostatecznie sprezentowałem ją sobie w grudniu 2012 roku i przeczytałem do końca parę miesięcy później. Obrazków faktycznie jest dużo i jest to książka idiotoodporna. Zawdzięczam jej nie tyle dokładne poznanie popularnych wzorców projektowych, ile zmianę sposobu myślenia. Książka przebudowała zupełnie moją ówczesną wiedze o OOP, wskazując wymierne korzyści w codziennych rozwiązaniach. Po jej przeczytaniu widziałem tyle zastosowań wzorców i ogólnie elastycznego OOP, że – jako neofita – chciałem zacząć wszystko na nie przerabiać. Początkowa fascynacja minęła, jednak nowy sposób myślenia został do dziś i jestem w stanie bez problemu wymienić mnóstwo rozwiązań z projektów, nad którymi pracuję, w których architekturze wykorzystałem wzorce i które – mimo niedoskonałości, które widzę po wielu latach – do dziś nie tylko dobrze się trzymają, ale są też dość odporne i łatwe do zmodyfikowania.

Drugą (i ostatnią) książką jest: Antywzorce języka SQL. Jak unikać pułapek podczas programowania baz danych (Bill Karwin). Na książkę tę trafiłem, gdy miałem już względnie duże doświadczenie z bazami danych i pewnie bym ją pominął, gdyby nie autor, którego kojarzyłem… ze stackoverflow. Jego odpowiedzi na tyle zapadły mi w pamięć jako rzeczowe i wyważone, że postanowiłem dać książce szanse. I nie pożałowałem – książka jest dość zwarta i zawiera opisane na przykładach antywzorce wraz z dokładnym wyjaśnieniem, dlaczego nie należy ich stosować i w czym utrudniają później pracę. Po przeczytaniu książki zauważyłem, że sam stosuję wiele z nich, więc dzięki niej mogłem świadomie przestać z nich korzystać na rzecz lepszych rozwiązań, sugerowanych przez człowieka z ogromnym doświadczeniem w tej (i nie tylko zresztą) dziedzinie.

Internet

Nikogo nie powinno zdziwić, że w przypadku webdevu większość materiałów, z których korzystam, znajduje się w internecie na wszelkiego rodzaju stronach czy blogach.

Jako pierwszy wymienię Stack Overflow. Ciężko znaleźć obecnie osobę, która go nie zna. Stack Overflow jest dla mnie najczęściej pierwszym krokiem do rozpoznania problemu. Odpowiedzi pozwalają na szybkie rozeznanie (w razie bardziej złożonych tematów) lub natychmiastowe rozwiązanie (w przypadku tych prostszych) problemu. Obecnie korzystam głównie biernie i raczej nie wspominam dobrze okresu, w którym starałem się odpowiadać na pytania użytkowników. Presja czasu w moim przypadku zabija całą zabawę w odpowiadaniu (trzeba napisać odpowiedź merytorycznie i bardzo szybko, inaczej po opublikowaniu okazuje się, że kilka osób zrobiło już to samo). Tym niemniej, SO stanowi ciągle ogromną bazę wiedzy na dość wysokim poziomie.

Drugim źródłem wiedzy są dla mnie wykopowe tagi #webdev oraz #php. Przeglądam je często w wolnym czasie. Dzięki nim dowiedziałem się o wielu stosowanych obecnie technologiach, których prawdopodobnie szybko zawodowo nie zastosuję, jednak wiedza o ich istnieniu przydaje się czasem w doborze narzędzi do rozwiązania danego problemu. Toczą się tam też dyskusje pozamerytoryczne związane z pracą zawodową w webdevie i pozwala to poznać opinie wielu doświadczonych ludzi. Tagi te przeglądam od 2014 i polecam każdemu śledzenie ich lub przeglądanie przez przynajmniej parę minut dziennie.