Pracując przy projekcie programistycznym, oprócz pisania kodu trzeba też m.in. zarządzać projektem – może to być uruchomienie testów, skonfigurowanie projektu czy wdrożenie projektu etc. Z reguły każde z takich zadań wymaga wykonania jakichś operacji, często wielu i w określonej kolejności – w tym miejscu „zapala się lampka”. Takie operacje można, a nawet trzeba, zautomatyzować! Dzięki temu uniknie się błędów wynikających z rutyny, znudzenia wykonywaniem ciągle tych samych operacji, bo czas można poświęcić na ciekawsze sprawy.

Dla programistów Javy znajomo brzmi nazwa Ant. Dla programistów PHP istnieje podobne narzędzie o nazwie Phing. W obu przypadkach, w skrócie, chodzi o możliwość „oprogramowania” różnych zadań związanych z projektem i późniejsze tylko uruchamianie odpowiednich procedur, które aplikacja zrobi za użytkownika.

Tym wpisem chciałbym rozpocząć cały cykl wpisów na temat narzędzia Phing, a ponieważ to pierwszy wpis zacznijmy od podstaw.

Instalacja

Instalacja narzędzia jest możliwa na kilka sposobów, wszystkie opisane są na tej stronie: http://www.phing.info/trac/wiki/Users/Installation. Poprawność instalacji, można zweryfikować poleceniem w konsoli:

root@cim-k52:~# phing -version
Phing 2.6.1

Użycie

Użycie Phinga do zarządzania projektem opiera się na utworzeniu i wypełnieniu pliku build.xml. Jak wskazuje rozszerzenie jest to plik XML. Dzięki temu nie trzeba się uczyć nowej składni (wystarczy znajomość podstaw XML). Dodatkowo działanie Phinga jest niezależne od systemu operacyjnego (włącznie ze ścieżkami do plików). Oprócz build.xml bardzo przydatne są pliki właściwości (*.properties), które są źródłem danych dla skryptu1.

Na początek kilka „słów kluczowych” odnośnie projektu z perspektywy Phing:

• project (projekt) – <project> to główny element w pliku build.xml, tzw. root node; definuje projekt, jego nazwę, opis, domyślny cel; dokumentacja
• target (cel) – <target> definiowane cele, które będzie można później wywoływać, np. konfiguracja projektu, wdrożenie na środowisko, uruchomienie testów; cele składają się z wywołań zadań; dokumentacja
• properties (właściwość) – <property> pozwala definiować właściwości, które w grunie rzeczy oznaczają zmienne skryptu; dokumentacja
• task (zadanie) – to konkretne zadania, których wykonanie składa się na osiągnięcie celu, np. skopiowanie/przeniesienie pliku, wgranie na serwer; w dokumentacji można znaleść listę dostępnych zadań

Na koniec pierwszego wpisu testowe uruchomienie, poniżej treść pliku build.xml:

<?xml version="1.0" encoding="UTF-8"?>

<project name="HelloWorld" default="hello">

    <property name="who"  value="World" />

    <target name="hello">
	<echo>Hello ${who}</echo>
    </target>

</project>

Plik build.xml najlepiej umieścić w głównym katalogu projektu. Podstawowym sposobem użycia jest wywołanie w katalogu zawierającym plik skryptu z poziomu konsoli:

cim@cim-k52:~/public_html/Phing$ phing hello
Buildfile: /home/cim/public_html/Phing/build.xml

HelloWorld > hello:

     [echo] Hello World

BUILD FINISHED

Total time: 0.0559 seconds

W powyższym przypadku wywołanie phing i phing hello daje ten sam efekt, ponieważ cel hello jest domyślnym celem projektu.

Komunikaty na konsoli pozwalają śledzić operacje (cele i zadania) wykonywane przez Phing (co jest szczególnie przydatne przy wywoływaniu celów, które zależą od osiągnięcia innych celów). Na koniec pojawia się komunikat o „BUILD FINISHED” informujący o poprawnym zakończeniu pracy, w innym wypadku pojawi się „BUILD FAILED” ze szczegółowym komunikatem błędu.

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

Zwiń
Czytaj na blogu autora...

Wczytywanie różnego rodzaju plików (zdjęć, dokumentów PDF itp) jest podstawową funkcją niemal każdego serwisu (niezależnie czy chodzi o backend, czy frontend). Jeszcze niedawno operacja ta była dostępna tylko za pomocą znacznika <input type=”file” /> (pomijam wykorzystanie Flasha i Javy), ale taki sposób nie był nigdy ani wygodny, ani estetyczny. Na szczęście, wraz z nadejściem HTML5 mamy takie zdarzenia JS jak drop i dragover.

Dzięki tym zdarzeniom oraz obiektowi XMLHttpRequest możemy przeciągać i wysyłać pliki tak łatwo jak w aplikacjach deskopowych. Spójrzmy na kod.

<!doctype html>
<html xmlns="http://www.w3.org/1999/xhtml">
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
        <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js" ></script>
        <style>
            body{
                font-size: 12px;
                font-family: Arial;
                color: #000000;
            }
            #drop_zone{
                padding: 20px;
                width:150px;
                border: 1px dashed #000000;
                text-align: center;
            }
        </style>
    </head>
    <body>
        <form method="post" action="upload.php" enctype="multipart/form-data">
            <div id="drop_zone">Przeciągnij tutaj plik</div>
            <output id="list"><ul></ul></output>
        </form>
        <script type="text/javascript">
            function handleFileSelect(evt) {
                xhr = new XMLHttpRequest();
                evt.stopPropagation();
                evt.preventDefault();

                var files = evt.dataTransfer.files; // FileList object.

                // files is a FileList of File objects. List some properties.
                var output = '';
                f = files[0];
                output += '<li><strong>' + escape(f.name) + '</strong> (' + f.type + ') - ';
                output += f.size + ' bytes, last modified: ';
                output += '<span class="info"></span></li>';
                $("#list ul").append(output);
                xhr.open("post", "upload.php", true);
                xhr.upload.onprogress = function(e) {
                    if (e.lengthComputable) {
                        var percentComplete = (e.loaded / e.total) * 100;
                        console.log(percentComplete + '% uploaded');
                        $("#list li:last .info").html("Wgrywanie..." + parseInt(percentComplete) + " %");
                        $("#drop_zone").html("Proszę czekać...");
                    }
                };
                xhr.onload = function() {
                    // do something to response
                    console.log(this.responseText);
                    $("#list li:last").css("color", "#008416");
                    $("#list li:last .info").html("Wczytano plik!");

                    $("#drop_zone").html("Przeciągnij tutaj plik");
                };
                var formData = new FormData();
                formData.append('file', f);
                xhr.send(formData);
            }

            function handleDragOver(evt) {
                evt.stopPropagation();
                evt.preventDefault();
                evt.dataTransfer.dropEffect = 'copy'; // Explicitly show this is a copy.
            }

            // Setup the dnd listeners.
            var dropZone = document.getElementById('drop_zone');
            dropZone.addEventListener('dragover', handleDragOver, false);
            dropZone.addEventListener('drop', handleFileSelect, false);
        </script>
    </body>
</html>

W funkcji handleFileSelect() za pomocą evt.dataTransfer.files pobieramy tablicę przeciągniętych plików. Następnie, za pomocą XMLHttpRequest przesyłamy plik na serwer. Dodatkowo dodałem komunikaty dla użytkownika informujące o „postępach” wysyłania plików.

Działanie skryptu możecie zobaczyć na tej stronie. Zachęcam do podejrzenia konsoli w Fireburgu .

W 2010 roku polecałem Wam korzystanie z APC, który miał w tamtym czasie bardzo dobre wsparcie, a na zaczął wtedy dominować PHP 5.3. APC z którego przede wszystkim wykorzystywano mechanizm cache opcode sprawiał się wyśmienicie, a w kodzie aplikacji nie trzeba było nic dostosowywać.

Niestety, dla nas wszystkich, w marcu 2012 roku ukazał się udoskonalony PHP (5.4), a do dzisiaj nie ukazała się stabilna wersja obsługująca tę wersję języka. Oczywiście APC działa pod PHP 5.4, ale w pewnych sytuacjach nie bardzo dogaduje się z PHP sypiąc segfault, lub po prostu kończąc wątek.

Całe szczęście na rynku pojawił się PHP 5.5, który oferuje nam możliwość skorzystania z wbudowanego akceleratora PHP – opcache szybszego o około 10-15% od APC. W początkowej wersji (5.5.0) posiadał jeszcze sporo niedociągnięć, ale obecnie można opcache (7.0.2) polecić. Jeśli mamy już PHP 5.5 wystarczy  w php.ini wprowadzić następującą modyfikacje:

opcache.enable=On

zend_extension=opcache.so

Opcache posiada zbliżone możliwości konfiguracji jak APC. Zalecane przełączniki dla opcache przez twórców:

opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000
opcache.revalidate_freq=60
opcache.fast_shutdown=1
opcache.enable_cli=1

Niestety, tak jak pisałem na Twitterze, opcache nie spełnia specyficznych wymagań. Jeśli na serwerze posiadacie serwisy chrootowane, które mają zbliżoną strukturę ścieżek to opcache zgłupieje. Nie bierze pod uwagę użytkownika jako który jest uruchamiany, ani ścieżki nadrzędnej, tylko te w chroot które są identyczne. W tym momencie jedynym pomysłem jest użycie unikalnych nazw katalogów zamiast docroot/.

Użytkownicy PHP 5.2, 5.3 i 5.4 nie muszą jednak ronić łez, opcache dostępny jest dla nich w PECL.

Jeśli potrzebujecie podejrzeć jak sprawuje się opcache, podobnie jak dla APC istnieje jedno plikowy opcache-status. Wystarczy umieścić go na serwerze i wywołać przez http.

Uważam, że PHP jest językiem bardzo „elastycznym”. Można napisać skrypt księgi gości (kto od takich rzeczy nie zaczynał? ) po przerobieniu tutoriala z internetu, można też napisać skomplikowaną i rozbudowaną aplikację internetową. W wszystko w jednym, tym samym języku.

Z jednej strony jest to zaleta – pozwala stosunkowo szybko osiągnąć działający efekt oraz pozwala się uczyć w obrębie jednego języka i rozwijać swoje umiejętności. Z drugiej strony jest to wada, bo pozwala pisać kod niechlujny, może nawet do tego zachęca/przyzwyczaja – skoro pierwsze efekty można było osiągnąć „metodą Copy’ego Paste’a”, to dlaczego kolejne mają wymagać więcej pracy?. W efekcie można spotkać dziwaczny kod, pełen funkcji zadeklarowanych tam gdzie akurat były potrzebne, zmiennych globalnych nagminnie używanych w metodach/funkcjach, kodu HTML, CSS, JS, PHP przemieszanego w obrębie jednego pliku etc. Obiektowość również się zdarza, ale budowa obiektów i ich wykorzystanie nie napawają optymizmem.

Myślę jednak, że nie należy winić języka. Jeżeli ktoś ma „głód wiedzy”, to taki kod będzie tworzył na początku, a później będzie się uczył, uczył i uczył jak programować coraz lepiej. Za cenną pomoc w tej nauce uważam dwie inicjatywy: PHP Framework Interop Group i PHP: The Right Way.

PHP Framework Interop Group

Jest to grupa ustalająca propozycje standardów dla kodu pisanego w języku PHP. Wypowiedzieć się w dyskusji może każdy chętny, jednak głosować mogą tylko przedstawiciele projektów (np. Zend Framework, Symfony2, Drupal, Doctrine, eZ Publish). Do tej pory grupa uzgodniła i zatwierdziła 4 standardy:

• PSR-0, Autoloading Standard – opisuje wymogi, jakie musi spełniać autoloader, żeby mógł obsługiwać różne biblioteki;
• PSR-1, Basic Coding Standard – opisuje ogólne wymogi kodu (kodowanie plików, tagi PHP, klasy, metody, właściwości, stałe);
• PSR-2, Coding Style Guide – opisuje szczegółowe zalecenia formatowania kodu;
• PSR-3, Logger Interface – opisuje interfejs dla loggerów, którego użycie umożliwi obsługę logów w różnych aplikacjach i bibliotekach z wykorzystaniem tego samego mechanizmu obsługi logów.

Nikt nie wymaga stosowania PSR-*, jednak uważam to za dobrą praktykę. Dodatkowo pisanie kodu przestrzegającego tych standardów może ułatwić jego późniejsze wykorzystanie jako bibliotek czy wykorzystanie w swoim projekcie zewnętrznych bibliotek.

Strona FIG znajduje się tutaj, jednak zawiera tylko zatwierdzone standardy. Natomiast propozycje kolejnych można znaleść na GitHubie grupy – tutaj.

PHP: The Right Way

Ten projekt jest zbiorem dobrych rad, kierunków rozwoju, narzędzi/technik którymi warto się zainteresować chcąc profesjonalnie programować w PHP. Dodatkowo zakres tematyczny jest bardzo szeroki – od pierwszych kroków, przez zarządzanie zależnościami (Composer, PEAR), po serwery, testowanie i cache. Dodatkowo strona jest przetłumaczona na język polski i dostępna tutaj.

W dniach 25-27 października odbyła się kolejna już edycja ogólnopolskiej konferencji PHPCon, znanej w kuluarach także jako „!DrupalCon” ;). Relacja tę piszę 27 października w drodze powrotnej do Poznania, tak więc wszelakie przemyślenia, które przeczytacie poniżej spisane są mocno na świeżo.

Miejsce i organizacja

Co rok, kiedy przychodzi temat PHPCona, tli się we mnie mała iskierka nadziei, że zorganizowana zostanie ona w miejscu z dość przystępnym dojazdem. Z roku na rok ta iskierka jest coraz mniejsza, bo i tym razem konferencja odbyła się, lekko mówiąc, w „mniej popularnej lokalizacji konferencyjnej” – mianowicie w Szczyrku.

PHPcon – Hotel Orle Gniazdo

Ogromny hotel, cały weekend, piękne krajobrazy. Tak, rozumiem już, że to się raczej nie zmieni i taka jest idea. Nie dziwię się równocześnie organizatorom, że nie myślą o zmianie podejścia, kiedy z roku na rok wszystkie miejsca są wyprzedane. Wydaje mi się, że duży wpływ na to ma także cena, ponieważ ok. 400zł za konferencję, jedzenie i nocleg to jest naprawdę super cena.

Tak więc kiedy standardowo ponarzekałem już na lokalizację, przejdźmy do dalszej części.

Hotel?. Ogromny. Ale mówiąc bardzo delikatnie – czasy swojej świetności ma za sobą. Zwłaszcza, jeśli otrzymało się zakwaterowanie w nieodnowionej części, )a byłem tym „szczęściarzem”. Widoki były naprawdę super, a równocześnie zastanawiam się, czy poranna niedzielna pobudka na trąbce należy do standardowych atrakcji tego hotelu.

Tak czy siak, „łoscypki” kupione :)

Jedzenie

Do hotelu przynależała naprawdę duża restauracja, która raczej nie miała problemu z pomieszczeniem wszystkich uczestników konferencji.

A samo jedzenie? Nie mam zastrzeżeń – nie było żadnych wykwintnych dań, ale to nie była wada. Zupa pieczarkowa, pierś kurczaka, na śniadanie pełen komplet (kiełbasa, jajecznica, wędliny, sery, warzywa, owoce). W sobotę wieczorem menu grillowe – karkówka, szaszłyki, pieczone ziemniaki, smalec – jak dla mnie pyszne.

A ciasto podczas sobotniego obiadu to zasługuje na osobną nagrodę :)

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

Zwiń
Czytaj na blogu autora...

It’s extremely important to have same state of the System Under Test. In most of the cases it will be possible by having same contents in a database for every test. I’ve decribed how to achieve it in Fully isolated tests in Symfony2 blog post about two years ago (btw. it’s most popular post on […]

W dniu wczorajszym została wydana najnowsza wersja PhpStorm oznaczona numerem 7. Wśród nowości w wersji 7 znaleźć można m.in.: wsparcie dla PHP w wersji 5.5 zmodyfikowane kolorowanie składni nowe opcje związane z refaktoringiem: przesuwanie statycznych zmiennych, wydzielenie interfejsu wbudowane narzędzia: Vagrant, konsola SSH, zdalne narzędzia, lokalny terminal wsparcie dla Zend Framework 2 Tool zmiany i […]