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:

• możliwości przeglądania artyułów wraz ze stronicowaniem;
• możliwość dodawania, edycji i usuwania artykułów z poziomu panelu administratora – dane dostępowe dostępne są po kliknięciu w link: „Przeglądaj panel administracyjny”;
• możliwość dodawania komentarzy do artykułów – wymagane odpowiednie uprawnienia użytkownika;
• formularz logowania i poziomy uprawnień użytkowników – dostęp do panelu admina wymaga wyższych uprawnień niż dostęp do częsci publicznej;
• wielojęzyczność aplikacji;
• RSS feed;

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.

phpcs

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:

<?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:

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

Zwiń
Czytaj na blogu autora...

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…

… czym w zasadzie jest ta „statyczna analiza kodu”

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.

Linter

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.

PHP Copy/Paste Detector (phpcpd)

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=*"

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

Zwiń
Czytaj na blogu autora...

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:

• obiektowy elementarz;
• programowanie zorientowane obiektowo;
• wielokrotne wykorzystywanie kodu;
• obsługa wyjątków;

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).

Xdebug

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 (Hierarchical Profiler) / XHGui

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_testing

Myś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):

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

Zwiń
Czytaj na blogu autora...

Pisałam ostatnio o tym jak można edytować projekt zdalnie, jednak doskonale wiem, że to nie jest najlepsze rozwiązanie i o wiele lepiej jest pracować na lokalnym serwerze a dopiero ukończoną wersję umieszczać na serwerze produkcyjnym. Do pracy na serwerze lokalnym potrzebny jest pakiet oprogramowania zwany w skrócie LAMP. L jak Linux A jak Apache (serwer […]