Niezalogowany [ logowanie ]
Subskrybuj kanał ATOM Kanał ATOM

Autor wpisu: matipl, dodany: 13.11.2018 16:08, tagi: php

Ale ten czas szybko płynie. Dopiero co opisywałem Wam przepis na kompilację PHP 5.4 (2013), a za rogiem czeka już PHP 7.3.

Mimo upływu 5 lat dużo się nie zmieniło w samej konfiguracji kodu źródłowego i kompilacji. Podstawa to posiadanie w Linuksie gcc/g++ oraz pakietów -dev (głównie pliki nagłówkowe .h), dla rozszerzeń z których będziemy korzystać. Poniżej lista pakietów dla Debiana, które są przydatne:

apt-get install make gcc g++ libxml2-dev zlib1g-dev bzip2 libbz2-dev libcurl4-gnutls-dev libjpeg8-dev libpng-dev libfreetype6-dev libmcrypt-dev libmysqlclient-dev lemon libtidy-dev libxslt1-dev libpcre++-dev libssl-dev automake autoconf libsystemd-dev pkgconf

Na pewno zapytacie po co to wszystko? W dawnych czasach nie wszystkie dodatki PHP były przygotowane w paczkach danej dystrybucji i po pewnym czasie trzeba było pobierać kod źródłowy, skonfigurować i skompilować i tak. Dlaczego nie zrobić tego od razu? W tamtych czasach również kompilacja pomagała odpowiednio sprofilować PHP pod daną konfigurację (czy ktoś jeszcze korzysta z Gentoo?). Obecnie główna przewaga takie podejścia, to posiadanie kilku różnych instanacji PHP w różnych wersjach na jednej maszynie (bo mamy różne projekty, różnych klientów etc). Jak również można sprofilować PHP pod konkretną jedną aplikację (prof-gen & prof-use).

Ja nadal zawsze kompilują PHP, wtedy w przypadku dysków HDD mamy ciut mniejsze obciążenia i większą swobodę działania. Jeśli już wykonałeś poprzedni krok wystarczy pobrać kod źródłowy wybranej przez nas wersji PHP (np. 7.2.12). Jeśli nie chcecie za każdym razie przeklikiwać się przez stronę https://php.net/downloads.php możecie użyć prostego skrypciku:

#!/bin/bash

if [ $# -eq 0 ]; then
  echo "Syntax : $0 php_version"
  echo "Example: $0 7.0.2"
  exit 1
fi
VERSION=$1
SHORT=${VERSION%.*}
SHORT=${SHORT//./}
FILE="php-$VERSION.tar.gz"
URL="http://pl1.php.net/get/$FILE/from/this/mirror"

HTTP_CODE=`curl --silent --head --location --output /dev/null --write-out '%{http_code}' $URL`
if [ $HTTP_CODE == 404 ]
then
   echo "Cannot download php-$VERSION - not found."
   exit 1
fi

wget $URL -O $FILE

Wtedy gdy dostaniesz informację o nowej wersji wystarczy, że wydasz polecenie ./php_get 7.2.12. Jak już mamy paczkę .tar.gz na dysku musimy rozpakować źródła i w katalogu, który powstanie umieszczamy nasz przepis na kompilację. Jak taki przepis wygląda? Wszystko zależy, z czego Wasze aplikacje PHP korzystają, a może jest to serwer, gdzie serwujecie rózne aplikacje i wymagacie różnych bibliotek. Mój uniwersalny przepis, z którego korzystam to:

make distclean
./configure \
--enable-opcache \
--prefix /usr/local/php72 \
--enable-fpm \
--enable-cli \
--enable-inline-optimization \
--disable-rpath \
--disable-ipv6 \
--enable-mbstring \
--enable-mbregex \
--enable-zip \
--with-pdo-mysql=mysqlnd \
--with-mysqli=mysqlnd \
--with-gettext \
--with-curl \
--with-zlib \
--with-zlib-dir=/usr \
--with-gd \
--with-jpeg-dir=/usr \
--with-png-dir=/usr \
--with-freetype-dir \
--enable-exif \
--enable-shmop \
--with-xsl=shared \
--enable-soap=shared \
--enable-sockets \
--enable-pcntl=shared \
--with-bz2 \
--with-tidy \
--with-pcre-dir \
--with-openssl \
--with-imap-ssl \
--with-pear \
--enable-pcntl \
--with-fpm-systemd
make -j2
make install

Czasami różni się w zależności od potrzeb. W dużym skrócie – sprzątamy po poprzedniej kompilacji, konfiguruejmy nasz przepis oraz puszczamy machinę w ruch. Opcja -j2 oznacza, że kompilacja wykona się na 2 jobach. Potrwa to dobrych kilka minut. I ostatecznie wszystko zainstaluje się zgodnie z przepisem, tj. w /usr/local/php72 (dzięki takiemu podejściu łatwo później posprzątać po poprzedniej wersji, np. php70).

Konfiguracja dla środowiska PHP jest czytana z lokalizacji /usr/local/php72/lib/php.ini (ja mam i tak w /etc/php72.ini, a we właściwym miejscu link symboliczny, ułatwia to tworzenie kopii zapasowych konfiguracj):

cp php-7.2.12/php.ini-production /etc/php72.ini
ln -s /etc/php72.ini /usr/local/php72/etc/php.ini
ln -s /usr/local/php72/etc/php.ini /usr/local/php72/lib/php.ini

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Autor wpisu: matipl, dodany: 08.11.2018 13:54, tagi: php

Ekipie ZaufanaTrzeciaStrona udało się wszystko dograć i już 1 grudnia odbędzie się pierwsza edycja konferencji What The H@ck. Jest to jednodniowa konferencja z kilkoma równoległymi ścieżkami. Łącznie odbędzie się 67 wykładów z przeróżnych tematów (od bezpieczeństwa aplikacji bankowych po bezpieczeństwo Internetu Rzeczy). Spotkacie tutaj takie postacie jak Piotr Konieczny, Michał Sajdak, Paula Januszkiewicz czy Łukasz „honey” Jachowicz.

Wydaje mi się, że nie muszę Ciebie zachęcać, jeśli tylko trochę związany(a) jesteś z branżą IT i rzucisz okiem na agendę:

What The H@ck 2018 - agenda

W takim razie do zobaczenia w sobotę, 1 grudnia!

Zapisy: What The H@ck Czas: 1 grudnia 2018, 9:00-18:00 Miejsce: Koszykowa 75, Warszawa (PW, Wydział MiNI) Bilety: obecnie 199 PLN brutto

Artykuł What The H@ck – nowa konferencja już w grudniu! pochodzi z serwisu Mateusz matipl Kamiński.

Autor wpisu: matipl, dodany: 18.10.2018 17:00, tagi: php

Chciałem już nie pisać o CodeSkill, to lokalne spotkanie i nie ma potrzeby, aby wciąż je promować. Ale o wczorajszym spotkaniu, szczególnie prelekcji Łukasza Sosnowskiego warto wspomnieć, ponieważ nawiązywała do PHP.

Łukasz przez prawie godzinę starał się pokazać, że każdy działający kod jest poprawny. Oczywiście kod może być „bardziej poprawny” lub mniej. I nie tylko chodzi o to, aby kod się uruchamiał i był zrozumiały. Bo powoli robi się to bardzo subiektywna opinia programisty.

A czy da się inaczej? Czy można skorzystać z jakiś metryk? Oczywiście, że tak. Łukasz wspomniał o złożoności cyklomatycznej (CC; liczba niezależnych ścieżek w programie) oraz mierze złożoności Halsteda (objętość, trudność napisania/zrozumienia kodu, utrzymanie kodu, szacunkowa ilość błędów). I nie są to subiektywne miary, ale miary z konkretnym uzasadnieniem matematycznym i merytorycznym (próba konstrukcji miar niezależnych od języka programowania).

Ogólna definicja mówi, że CC to liczba niezależnych ścieżek w grafie reprezentującym przepływ sterowania w metodzie. Istnieją dwa wzory określające tę wartość: pierwszy opiera się na liczbie wierzchołków i łuków w grafie, natomiast drugi – jedynie na liczbie węzłów decyzyjnych. (źródło)

Teorii było bardzo niewiele – słusznie, ponieważ można znaleźć ją w Internecie. Natomiast sporo było przykładów z życia. Były zaprezentowane 2-3 zadania z życia, i każde rozwiązane na kilka sposobów wraz z prezentacją ich metryk.

Jednym z nich było zadanie związane z napisaniem funkcji, która przyjmuje 3 parametry (ulica, miasto, kod) i na wyjściu powinien być string sformatowany w następujący sposób: Ulica, Miasto Kod . Pierwsze rozwiązanie (wariant) pojawił się bardzo szybko i wyglądał następująco:

function address(?string $street, ?string $city, ?string $zip): string
{
    $fullAddress = !empty($street) ? $street : '';
    if (empty($city) && empty($zip)) {
        return $fullAddress;
    }
    if (!empty($fullAddress)) {
        $fullAddress .= ', ';
    }
    if (!empty($zip)) {
        if (!empty($city)) {
            $fullAddress .= $city . ' ';
        }
        $fullAddress .= $zip;
    } else {
        $fullAddress .= $city;
    }
    return $fullAddress;
}

Ale w zespole, o którym mówił prowadzący nie wszystkim przypadła do gustu tak duża ilość warunków i ktoś szybko pokazał wariant drugi:

function address2(?string $street, ?string $city, ?string $zip): string
{
    $zipPart = implode(' ', array_filter([$city, $zip]));
    return implode(', ', array_filter([$street, $zipPart]));
}

Niestety. Mimo, że jest to ładniejsze rozwiązanie to okazało się mało wydajne (0,35μs vs 0,53μs). Po długim czasie, zupełnie przypadkiem powstało rozwiązanie piąte, które wyglądało następująco:

function address5(?string $street, ?string $city, ?string $zip): string
{
    return trim(
        $street . ", ". trim($city . " " . $zip),
        ", "
    );
}

Metryki dla wszystkich 5 rozwiązań: Poprawny kod - zad. 1, metryki

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Autor wpisu: matipl, dodany: 11.10.2018 15:47, tagi: php

Brakuje mi starego, poczciwego PHPCon Poland, które było małym, integracyjnym spotkaniem miłośników PHP. Pamiętacie Góry Świetokrzyskie? 90 osób odciętych od świata, trzeba było iść na Święty Krzyż aby złapać GSM

Autor wpisu: matipl, dodany: 19.09.2018 16:24, tagi: php

W tym roku byłem powtórnie na konferencji PHP Srbija. W 2017 roku to nie był żaden eksperyment z mojej strony. Obserwowałem chłopaków z Belgradu od dawna. Nabrali w 2013 roku niesamowitego tempa i co roku (2013 – Google Code Day, meetupy; 2014 – TestingDay; 2015 – SOLIDay) pracowali nad tym co dzisiaj znamy jako konferencja PHP Srbija. Po pierwszej edycji (2016) uznałem, że muszę tam być i przekonać się na miejscu, że w dzisiejszych czasach można zrobić coś tak niesamowitego.

Serbia i Chorwacja to mało liczebne kraje (odpowiednio 7 i 4 mln mieszkańców), dlatego wydaje mi się, że tak mocno chcą rywalizować z innymi, pokazać, że również Serbowie i Chorwaci potrafią. W porównaniu z konferencjami z innych państw, „tutaj” od razu starają się organizować całość po angielsku (PHP Srbija, Web Summer Camp, WebCamp Zagreb itp.) – i to działa, ściagają tutaj najlepsi prelegenci i uczestnicy z całej Europy.

Belgrad - widok na Dunaj

PHP Srbija jest rewelacyjna pod każdym względem. Madlenianum Theatre, piękne miejsce w uroczej dzielnicy Belgradu nad Dunajem. Podczas dłuższej przerwy (lunch) można przejść się nad rzekę, wdrapać na pobliskie wzgórze, aby zobaczyć milenijną wieżę i uroczą panoramę. Powitanie, przerwy kawowe, obiad – bardzo wysoki poziom, ludzi w sam raz, widać, że organizatorom naprawdę zależy, aby wszyscy czuli się dobrze, a sama konferencja kojarzyła się tylko z dobrymi wspomnieniami.

Na plus dla konferencji można zapisać też czas kiedy się odbywa – koniec tygodnia. Jest wtedy mniejszy konflikt z innymi obowiązkami. Same prelekcje odbywają się w sobotę i niedzielę (10:00-18:00), dla chętnych dodatkowo są warsztaty w piątek (8:30-18:00). Bardzo odpowiada mi także, że PHP Srbija jest w miesiącu maju – na spokojnie jeszcze przed latem i nie jest tak gorąco. Belgrad obecnie jest dobrze skomunikowany z Warszawą – LOT-y odbywają się codziennie.

Tylko na plus

Sama konferencja jest podzielona na 2 ścieżki równoległe, po prostu ścieżka A i B oraz gromadzi około 600 uczestników. Dzięki temu można lepiej dopasować tematy do siebie. I faktycznie z tego korzystam. Nie ma tematów dla prawdziwych nowicjuszów, ale poziom jest zróżnicowany (od średnio zaawansowanego do tematów dla wieloletnich programistów i freelancerów). Podobnie tematyka jest przeróżna. Od tematów związanych z testowaniem oprogramowania, samą architekturą po „nowinki” dzisiejszych czasów jak kontenery, event sourcing, DDD.

Belgrad - grajek uliczny

Oczywiście nie jest tak, że każdemu uczestnikowi wszystkie tematy podpasują, albo sami organizatorzy dostaną zgłoszenia samych perełek. Moim zdaniem trzeba się liczyć z tym, że na konferencji do 30% tematów może nie być trafionych, lub po prostu prelegent nie potrafi dobrze przedstawić zagadnienia, tematu z którym przyjeżdża.

Centrum wydarzeń

Dla mnie Bałkany stały się małym zagłębiem dla programistów PHP (PHP Srbija czy też Web Summer Camp) – poziom jest bardzo dobry, a do tego na naszą kieszeń (słowiańską). Czujemy się trochę jak u siebie – język i kultura bardzo podobna. Do tego bardzo dobre prelekcje i warsztaty. Wydaje mi się, że w ciągu roku 2-3 konferencje są w sam raz. Przy większej ilości tematy zaczynają się po prostu powtarzać i nie ma większego sensu, aby marnować swój czas i pieniądze, aby objeżdżać cała Europę i słuchać podobnych prelekcji (a nieraz dokładnie tych samych.

Trzy słowa o prelekcjach 2018

Nie chciałem wspominać o samych prelekcjach wiosennych, bo mamy prawie jesień. Ale postaram się Wam przybliżyć w trzech słowach co zapamiętałem z PHP Srbija 2018.

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Autor wpisu: matipl, dodany: 13.09.2018 17:21, tagi: php, symfony

Nadal zbieram się, aby podzielić się z Wami wrażeniami po PHP Srbija 2018, ale ciężko mi to zrobić bez zdjęć. A zdjęcia ciągle są nieprzejrzane i koło się zamyka. Ale…

W poniedziałek byłem na powakacyjnym PHPers Trójmiasto w C200 Office. Jeśli dobrze sięgam pamięcią ostatni raz byłem w 2014 roku (!), kiedy spotkania odbywały się jeszcze w PPNT. W tamtym czasie lokalne PHPersy dopiero startowały (obok Warszawy pojawiło się Trójmiasto oraz Śląsk). Nie wiem skąd wynikła przerwa, może brak systematyczności spotkań i lokalizacja źle skomunikowana.

Czemu wybrałem się tym razem? Dobre pytanie. Może brakuje mi PHPCon Poland i szukam czegoś w zastępstwie w Polsce. Do Pragi na PHP CE się nie wybieram – dla mnie będzie to zupełnie inna konferencja, poza tym grafik spotkań zagranicznych i tak jest już napięty. W tym roku nie było również Zimowiska Linuksowego. I tak trochę PHPers Trójmiasto potraktowałem jako mały event z ograniczoną ilością uczestników. Powiem Wam: było warto!

testy jednostkowe

Poniedziałkowe spotkanie związane było z testami jednostkowymi (w oparciu o phpSpec i phpUnit) oraz podsumowaniem zmian jakie zaszły w Symfony 4, oraz czym tak naprawdę jest Flex.

PHPers Trójmiasto - Leszek Prabucki Ci z Was, którzy byli tam wraz ze mną, wiedzą najlepiej, że ciężko napisać coś o prelekcji i kodowaniu na żywo Leszka Prabuckiego. Nie chodzi o to, że było źle. Leszek bardzo fajnie i szybko pokazał nam jak może wyglądać zwyczajny dzień pracy programisty, gdy dostajemy od Klienta np. zlecenie wykonania rejestracji do systemu. Od spotkania z Klientem, event stormingu itp., poprzez napisanie pierwszych testów (phpSpec), refactoringu, stworzeniu domeny (zalążek DDD) i skupieniu się na tym co chce Użytkownik zrobić, a nie jak. To było po prostu specyficzne doświadczenie.

PHPUnit Good Practices

Natomiast Dariusz Rumiński, który pracuje w Delivery Hero (PizzaPortal), rozwinął myśl Leszka z naciskiem na same testy jednostkowe oraz jak to zrobić dobrze w oparciu o phpUnit. Darek pracuje z phpUnit od wersji 3.3 (2008). Przez lata phpUnit się zmieniał, przechodził metamorfozy, jedne funkcje się pojawiały, a inne niestety znikały. Obecnie phpUnit posiada pewną warstwę abstrakcji, tzn. kompatybilności, ale nie daje ona nam wszystkiego i musimy o tym pamiętać aktualizując phpUnit już w istniejącym projekcie z istniejącymi testami. Oferuje również ponad 100 gotowych porównań (assertions).

Nieraz zdarza się, że nasze testy nie mogą obejść się bez atrap (mocks). Obecnie phpUnit pozwala w różny sposób tworzyć atrapy. Od starodawnego MockObject, poprzez Mockery, kończąc na współczesnym i zalecanym Prophecy, który już nie jest powiązany ze strukturą. I najważniejsze o czym trzeba pamiętać – pisać testowalny kod.

Symfony 4 i Flex

Tematem zamykającym spotkanie był Symfony 4 i Flex. Jakub Zalas niesamowicie poprowadził swoją prelekcję (pomijając fakt wspomnienia jego największego osiągnięcia). Jakub pokazał czym tak naprawdę jest Symfony 4, czyli Symfony 3.4, które de facto jest odchudzoną i zmienioną wersją Symfony 3.3, a te wersji 3.2 itd. Ale taki był zamysł twórców Symfony 2, że kolejne wydania będą często, ale nie będą przynosiły rewolucji (jak Sf2).

W dużym skrócie, jakie zmiany przynosi Sf4? Ulepszona struktura projektu. Nie ma już folderu na aplikacje (/app), a aby dostosować się do całego środowiska PHP zmieniono chociażby /web na /public. Dodatkowo pojawia się .env ze zmiennymi konfiguracyjnymi, które powinno być używane dla środowisk developerskich. Natomiast w konfiguracji nie ma już głównego pliku konfiguracyjnego. Każdy pakiet może mieć swojego yml. Pojawia się również bundles.php do konfiguracji jakich bundle’i chcemy używać w projekcie (wszystkie te informacji dzieją się obecnie automatycznie dzięki autowire i Flex). Flex przynosi również aliasy dla composera (np req templates zainstaluje twig). Core Team wybrał aliasy dla najbardziej zalecanych paczek.

A najważniejsza zmiana, jak dla mnie? Symfony 4 na dysku zajmuje 14MB (Sf3.4 ~ 58MB), tym samym spadła ilość plików do 2.5k (Sf3.4 8.9k). Co przyspiesza działanie aplikacji, ale bez wspomnianego opcache i tak się nie obędzie.

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Autor wpisu: matipl, dodany: 12.09.2018 14:28, tagi: php

W odległych czasach przed PHP 5.2 (listopadem 2006) biblioteki w PHP były małe, frameworki dla PHP prawie nie istniały, dopiero tworzył się Zend Framework 1.0. A aplikacje PHP najczęściej wykorzystywały jeden wzorzec MVC, jeśli w ogóle były tworzone obiektowo.

Aby PHP w tamtym czasie było szybkie nie potrzeba było wiele (głównie I/O bazy). Ale czas zaczął niesamowicie szybko biec, Internet stawał się coraz popularniejszy, pojawiły się przeglądarki mobilne. Tym samym powstawało coraz więcej narzędzi, bibliotek, dodatków, a sama ilość żądań rosła niesamowicie. Pojawił się Zend Framework 2 (wrzesień 2012) oraz Symfony 2 (lipiec 2011), a wraz z nimi tysiące plików PHP potrzebne tylko do jednej aplikacji. Dla przykładu Symfony 3.4 to 50 MB danych umieszczonych w prawie 9 tysiącach plików.

W dużym skrócie, bo już kiedyś o tym wspominałem, PHP nie był w stanie szybko ogarniać dostępu do tylu plików na raz, przy każdym wykonaniu kodu, przy każdym wywołaniu żądania o aplikację internetową musiał dysku odpytać o wszelkie potrzebne kody źródłowe. Tworzenie cache całego serwisu (do HTML) było tylko pewnym obejściem problemu, ale nie jego rozwiązaniem.

Tak powstały akceleratory PHP, a bardzo szybko dominację na rynku zdobył opcache, który wraz z wersją PHP 5.5.0 został na stałe dołączony do silnika. Niestety od samego początku miał jedną wadę w połączeniu z php-fpm – nie był przygotowany na chroot’owanie.

Na poziomie php-fpm silnik nie wiedział już jaki jest główny katalog, dla niego głównym katalogiem był katalog bieżący. Na przykład, mamy aplikację w katalogu /var/www/app.domain.com/docroot, z włączonym chrootem, dla PHP-FPM i opcache widoczny jest wyłącznie /docroot, a jeszcze częściej sam /.

Korzystanie z chroot (czyli funkcji, aby aplikacje wzajemnie na siebie nie oddziaływały) powodowało, że nie mogliśmy korzystać z opcache. Dlaczego? Opcache powodował tworzenie takich samych skrótów dla różnych aplikacji (np. WordPress, ZF, Sf przenikały się wzajemnie powodując błędy).

Całe szczęście core team wraz z wersją PHP 7.0.14 (grudzień 2016) dodał parametr konfiguracyjny opcache.validate_root, którego włączenie sprawia zapobieganie kolizjom nazw w chroot oraz faktycznym chroot, również z poziomu php-fpm.

opcache.validate_root = 1

I w końcu, można od PHP 7.0.14 cieszyć się chroot’em oraz opcache.

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Wszystkie wpisy należą do ich twórców. PHP.pl nie ponosi odpowiedzialności za treść wpisów.