W lutym świtało dzienne ujrzała pierwsza oficjalna wersja aplikacji demo dla frameworka Symfony. Aplikacja demo istniała już wcześniej i była bardzo ciekawym żródłem z przykładami wykorzystania podstawowych możliwości Symfony – przede wszystkim dla osób nie znających tego frameworka – sam niejednokrotnie polecałem ją na szkoleniach dla początkujących z Symfony. W tym momencie demo ewoluowało, zostało dostosowane do nowości, które pojawiły się zarówno w ostatnich wersjach frameworkach oraz PHP i jest aktywnie rozwijane.
Aby wygenerować aplikację „demo” wystarczy z wiersza poleceń wprowadzić polecenie:
# using Symfony installer symfony demo
wykorzystując do tego instalator Symfony, który możecie znaleźć tutaj.
Następnie należy załadować dane testowe by móc w pełni korzystać z aplikacji demo. I to wszystko – nie ma potrzeby wywyoływania dedykowanych komend dla danych testowych: zostały odpowiednio przygotowane podczas instalacji projektu demo.
Aplikacja posiada wszystkie podstawowe funkcjonalności jakie możemy znaleźć na blogu wraz z kodem zródłowym i obszernymi komentarzami:
Dodatkowo aplikacja demo pokazuje w jaki sposób korzystać z zewnętrznych bundli (PagerFanta dla stronicowania), w jaki sposób definiować własne typy pól formularza (DatePicker, tagowanie artykułów), jak zarządzać uprawnieniami użytkowników czy też jak prawidłowo definiować realcji pomiędzy encjami w Doctrine2. Kod aplikacji demo znajduje się na GitHubie, gdzie można wysyłać propozycje nowych / brakujących funkcjonalności czy też zgłaszać błędy.
Artykuł Symfony: aplikacja demo pochodzi z serwisu Notatki Programisty.
PhpUK is a conference I have wanted to attend for a long long time. I had watched all the videos on youtube really carefully for the last few years and always got this weird feeling this might be one of the best and most important conferences in Europe. So, here I am. 3 totally different […]
W tym poście będę kontynuował rozpoczętą w ostatnim wpisie prezentację narzędzi do analizy statycznej kodu PHP.
Dzisiaj zajmę się tylko jednym narzędziem – chodzi mianowicie o PHP_CodeSniffer.
Tak naprawdę jest to zestaw dwóch skryptów. Pierwszy z nich to phpcs – oznacza on fragmenty kodu, które nie są zgodne z ustawionym standardem kodowania zaś drugi skrypt nazywa się phpcbf koryguje te nieścisłości. PHP_CodeSniffer można zainstalować zarówno za pomocą Pear jak i Composera. Sam projekt można znaleźć na GitHubie pod tym adresem.
Przyszedł czas na krótką prezentację możliwości PHP_CodeSniffer. W tym celu stworzyłem plik TestSa.php zawierający klasę o tej samej nazwie:
Kanał ATOM
<?php
class TestSa extends AnotherClass{
function __construct($argument){
if (true) {
return true;
}
return false;
}
}
Ja zainstalowałem PHP_CodeSniffera lokalnie w projekcie więc w CLI wpisuję następujące polecenie:
php vendor/bin/phpcs ./TestSa.php
Zamiast w konsoli wpisywać osobno polecenie dla każdego pliku (a w projekcie może być ich naprawdę dużo) można zamiast adresu pliku podać adres katalogu, w którym znajduje się projekt. Efekt działania tego polecenia jest podobny do tego na obrazku poniżej:
Jedna z ostatnich prelekcji na jakiej zjawiłem się podczas zeszłorocznego PHPCon była poświęcona statycznej analizie kodu. Bardzo lubię ten temat ponieważ odpowiedni zestaw narzędzi zarówno na komputerze jak i na serwerze CI jest bardzo pomocny w utrzymywaniu kodu aplikacji w dobrej kondycji. Często okazuje się jednak, że nawet doświadczeni programiści nie stosują albo nawet nie wiedzą co to jest statyczna analiza kodu.
W tym poście mam zamiar opisać te najprostsze wg mnie narzędzia do statycznej analizy kodu PHP bezpośrednio wspomagające sam proces programowania. W drugiej części opiszę narzędzie zwane PHP_CodeSniffer, w trzeciej PHP Mess Detector. Ostatnią czwartą części tego postu opiszę narzędzia, które służą do analizy całych projektów lub wspomagają np. migrację projektu na inną wersję PHP. Zanim jednak zajmę się samymi narzędziami warto było by odpowiedzieć sobie na podstawowe pytanie…
Najprościej rzecz ujmując jest to analiza kodu bez jego uruchamiania. Statyczna analiza kodu jest przeciwieństwem dynamicznej analizy kodu. Przykładowo jeśli używasz Xdebug lub podobnego narzędzia stosujesz właśnie analizę dynamiczną. Dzięki (dynamicznej analizie kodu) można np zerknąć co znajduje się w konkretnej zmiennej, sprawdzić lub zdiagnozować, w którym miejscu aplikacja zużywa najwiecej pamięci.
Analiza statyczna koncentruje się przede wszystkim na samym kodzie, na stylu kodowania, na utrzymaniu porządku w kodzie etc.
Jako pierwsze opiszę linter w PHP – czyli narzędzie, które mamy dostępne od razu po instalacji PHP. Jeśli nie wiecie dokładnie, czym zajmuje się linter możecie uzupełnić swoją wiedzę w tym miejscu. W skrócie jest to narzędzie, które oznacza podejrzane lub błędne fragmenty kodu.
W PHP aby uzyskać dostęp do lintera należy w CLI wpisać php -l a zaraz po tym ścieżkę do pliku, który chcemy poddać analizie. Oczywiście wpisywanie za każdym razem polecenia w CLI dla pliku, w którym wykonaliśmy jakąś zmianę byłoby bardzo męczące dlatego też istnieje szereg rozszerzeń różnych edytorów dla programistów takich jak Atom czy Sublime Text 3. Oczywiście nie tylko PHP posiada linter – odpowiednie rozszerzenia istnieją także dla JavaScript i innych języków.
Kolejne narzędzie jest bardzo pomocne przy wykrywaniu powtarzających się fragmentów kodu czyli tzw copy/paste programming. Autorem PHPcpd jest Sebastian Bergmann najbardziej znany chyba z PHP Unit.
Samo narzędzie można zainstalować Composerem lokalnie w projekcie:
composer require "sebastian/phpcpd=*"
Pierwsza edycja warsztatów cieszyła się bardzo dużą popularnością, dlatego podjeliśmy decyzję o kontynuacji warsztatów z podstaw programowania w PHP. Tym razem warsztaty będą przede wszystkim dotyczyły zagadnień związanych z programowaniem obiektowym w PHP 5.X,
Warsztaty odbędą sie 11 lutego (sobota) 2017 r. w godzinach 9:00 – 12.30 w sali komputerowej Wyższej Szkoły Przedsiębiorczości i Administracji w Lublinie przy ul. Bursaki 12. Udział w warsztatach jest bezpłatny, a liczba miejsc ograniczona. Wymagana jest wcześniejsza rejestracja na wydarzenie poprzez formularz znajdujący się na fanpagu wydarzenia. Krótki plan warsztatów znajduje się poniżej.
Warto wiedzieć, że:
Mimo że wydarzenie jest kierowane do kobiet, mężczyźni również są mile widziani, jeśli interesują ich tematy prezentacji. Choć wśród organizatorek są wyłącznie kobiety, nie znaczy to, że zamykamy się na panów. Publiczność na naszych warsztatach i spotkaniach jest zawsze mieszana, a panowie często występują u nas także w roli prelegentów.
Co w wolnym tłumaczeniu oznacza, że warsztaty są otwarte dla wszystkich – nie tylko dla kobiet (po więcej informacji odsyłam na stronę WiT ).
Zakres zagadnień, które będę poruszał na warsztatach:
Wszystkich zainteresowanych serdecznie zapraszam!
Artykuł Warsztaty z programowania obiektowego w PHP – WiT Lublin pochodzi z serwisu Notatki Programisty.
W pewnym momencie życia naszej aplikacji przychodzi taka chwila, że staje się dla nas ważna wydajność. Często jest to powiązane ze wzrostem ilości zapytań/użytkowników lub danych w bazie. Ale nie zawsze wiemy jak zabrać się do pomiarów naszej aplikacji (obciążenia procesora, zużycie pamięci, czasu przebiegu).
W odległych czasach często obudowywano fragmenty kodu PHP w taki sposób:
$start = microtime(true); someFunction(); $end = microtime(true); $executionTime = number_format($end - $start, 10);
Dzięki temu uzyskiwaliśmy pewną wiedzę na temat czasu wykonywania metod, funkcji, fragmentów kodu. W podobny sposób uzyskiwano informacje np. odnośnie pamięci. Następnie zapisywaliśmy dane do bazy, pliku etc. Całość jednak powodowała dość duży narzut prac, aby sprawdzić wydajność aplikacji, a jednocześnie w pewnych sytuacjach powodowała zwiększenie złożoności kodu (dodatkowe modele, biblioteki, klasy).
Jeśli ktoś znał Xdebuga i miał możliwość włączenia na serwerach developerskich/testowych rozszerzeń PECL bardzo szybko przenosił się na to rozwiązanie. Profilowanie w Xdebug jest bardziej uniwersalne, nie musimy osobno „badać” każdej metody, ale robi to sam Xdebug na poziomie wykonywania kodu PHP i zbiera naprawdę sporo informacji o wszelakim wykonanymi kodzie. Wystarczy tylko odpowiednio skonfigurować mechanizm profilowania w php.ini:
xdebug.profiler_enable = 1 xdebug.profiler_output_dir = /tmp/profiler
Po każdym request do aplikacji otrzymujemy plik cachegrind.out we wskazanym katalogu, który możemy przenalizować za pomocą narzędzi graficznych, np. takim jak KCachegrind. Jest to dobre rozwiązania na maszynie developerskiej, gdzie jest ograniczona ilość użytkowników, możemy kontrolować ilość requestów, ponieważ w innym wypadku bylibyśmy zawaleni przez pliki z proflowania. Poza tym narzędzie Xdebug nie jest zalecane do zastosowań produkcyjnych. Co w takim wypadku?
XHProf został stworzony przez developerów Facebooka i udostępniony publicznie w marcu 2009 roku. Tak jak Xdebug jest również napisane w C jako PHP Zend Extension (PECL). Ale zadaniem XHProf jest wyłącznie profilowanie naszej aplikacji (zbiera takie metryki jak czas, czas CPU czy użycie pamięci). Został stworzony z myślą, aby działać na środowiskach produkcyjnych (stabilność, mały narzut na zbieranie informacji). XHProf dostarcza również prosty mechanizm do tworzenia raportów HTML, w którym możemy przeglądać rezultaty profilowania, jak również zobaczyć graf przejścia. Rozszerzenia znajduje się w oficjalnym katalogu PECL, dlateg aby zainstalować XHProf wystarczy wydać komendę:
pecl install xhprof
Bazując wyłącznie na XHProf możemy wykorzystać dość toporny sposób na zbieranie informacji:
//operations, collecting
xhprof_enable(XHPROF_FLAGS_CPU + XHPROF_FLAGS_MEMORY);
for ($i = 0; $i < = 1000; $i++) {
$a = $i * $i;
}
$xhprof_data = xhprof_disable();
//writing
$XHPROF_ROOT = "/tools/xhprof/";
include_once $XHPROF_ROOT . "/xhprof_lib/utils/xhprof_lib.php";
include_once $XHPROF_ROOT . "/xhprof_lib/utils/xhprof_runs.php";
$xhprof_runs = new XHProfRuns_Default();
$run_id = $xhprof_runs->save_run($xhprof_data, "xhprof_testing");
//URI with data:
//http://127.0.0.1/xhprof/xhprof_html/index.php?run={$run_id}&source=xhprof_testingMyślicie, że to skomplikowane i dużo nie ułatwia? Zgadzam się! Dlatego od razu polecam zapoznać się z XHGui, który cały proces upraszcza i niweluje tworzenie wielu małych plików dostępnych pod unikatowym ID, bez których nie jesteśmy w stanie szybko zapoznać się z analizą.
XHGui napisany jest w PHP i jest to forma nakładki na profiler. Cały kod XHGui umieszczamy w miejscu dostępnym tylko dla nas przez WWW i robimy zmianę w php.ini (lub przeciążamy zmienną w naszym kodzie):