Niezalogowany [ logowanie ]
Subskrybuj kanał ATOM Kanał ATOM    Subskrybuj kanał ATOM dla tagu php Kanał ATOM (tag: php)

Autor wpisu: zleek, dodany: 21.04.2017 10:31, tagi: javascript, php

As we tak a look on websites, we can easily see that most of them have contact form built in. But having this contact form could switch to huge amount of spam messages sent by using that form. Fortunatelly we

Autor wpisu: Piotr Śliwa, dodany: 29.03.2017 19:19, tagi: php

Ostatnio przygotowywałem pull requesta dla biblioteki typesafe/config - prosty ficzer. Okazało się, że po moich zmianach build na windowsach przestał przechodzić. Po czasochłonnej inwestygacji, debugowaniu i namierzaniu problemu, okazało się, że winowajcą jest tytułowy TimeZone.getDefault(). Gdy to odkryłem, uświadomiłem sobie dlaczego tak bardzo doceniłem niemodyfikowalne obiekty, brak side effectów i czyste funkcje.

W czym był problem? Pliki HOCON (format plików konfiguracyjnych wspierany przez tą bibliotekę) mogą includować inne pliki konfiguracyjne. Do odczytywania takich plików używana jest klasa URLConnection. W implementacji tej biblioteki wywoływana jest funkcja URLConnection.getContentType() aby sprawdzić jakiego typu plik jest wczytywany. Metoda ta pobiera nagłówki połączenia, w którym jest data ostatniej modyfikacji. Jeśli jest data, to trzeba ją sformatować. Klasa SimpleDateFormat używa domyślnej strefy czasowej, chyba że powiemy jej inaczej. TimeZone.getDefault(), wbrew sugestywnej nazwie i zasadzie najmniejszego zaskoczenia, ma side effect, a jak! Jak to, dlaczego? Bo może! Wywołuje bowiem System.setProperty("user.timezone", <strefa czasowa>) jeśli takie property nie jest jeszcze ustawione. Pech w tym, że typesafe/config wczytuje java propertisy robiąc w testach asercje na tychże wartościach. W zależności czy TimeZone.getDefault() było wcześniej wywołane i czy user.timezone było jawnie ustawione, testy mogły failować lub też nie (co też miało miejsce).

Autor wpisu: zleek, dodany: 09.03.2017 15:13, tagi: php

Sometimes we have to apply dynamic data (fetched from database) to form fields. Good example is to deliver an option to choose a preferred language during user registration. Let say we have two available languages on the begining, but we

Autor wpisu: Piotr Pasich, dodany: 22.02.2017 07:38, tagi: php

phpukPhpUK 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 […]

Autor wpisu: Michał Janicki, dodany: 19.02.2017 22:45, tagi: php

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

Autor wpisu: Michał Janicki, dodany: 29.01.2017 22:36, tagi: php

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

Autor wpisu: matipl, dodany: 13.01.2017 12:43, tagi: php

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

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