Kilka miesięcy temu popełniłem wpis zatytułowany Warsztat programisty PHP, w którym wymieniłem najważniejsze narzędzia jakimi posługuje się (powinien posługiwać się) programista PHP. Dzisiejszy wpis będzie stanowił rozwinięcie zawartym w nich informacji. Na pierwszy ogień idzie IDE.

Czasy, w których do tworzenia aplikacji internetowych (nazywanych wtedy stronami) wystarczył notatnik lub dowolny inne nieskomplikowany edytor, minęły bezpowrotnie. Dzisiaj, aby móc pracować nad większością projektów, niezbędne jest IDE, czyli kombajn usprawniający naszą pracę. Na rynku mamy dostępnych co najmniej kilka dobrych aplikacji i nie da się jednoznacznie stwierdzić, która z nich jest najlepsza. Przez długi czas pracowałem na Eclipse, miałem styczność z Netbeansem, a obecnie wszędzie gdzie to możliwe, wykorzystuję PhpStorm.

Co cechuje dobre IDE? Przede wszystkim wygoda w używaniu. IDE nie powinno przeszkadzać programiście, który ginie w gąszczu skrótów klawiaturowych, setek zakładek i milionach ustawień. Dobre IDE musi być gotowe do pracy od razu po instalacji, bez konieczności poświęcania połowy dnia na jego konfigurację. Ważna jest również prędkość jego działania. Sytuacja, w której oczekiwanie na podpowiedź kodu zajmuje więcej czasu niż sprawdzenie w dokumentacji jest niedopuszczalna.

Porządne IDE pozwala na pracę ze wszystkimi sposobami zapisywania danych – systemy kontroli wersji oraz FTP/SFTP. Bez tego będziemy żonglować oknami, co w krótkim czasie spowoduje liczne problemy. Nie można również zapomnieć o najprostszym nawet interfejsie wyświetlającym dane z bazy danych, które co jakiś czas musimy sprawdzić lub zmienić.

Równie istotne jest proste debugowanie kodu. IDE powinno być w stanie wyłapać najczęstsze pomyłki popełniane w kodzie oraz pokazać, w którym miejscu w kodzie źle wstawiliśmy średnik, przecinek, klamrę lub dowolny inny niechciany znak. Poza samym wskazywaniem błędów, istotna jest możliwość korzystania z zaawansowanych debugerów (np. Xdebug).

Na koniec pozostaje możliwość integracji IDE z zewnętrznymi narzędziami wspomagającymi deploy aplikacji na sewer/do chmury, wspomagającymi tworzenie testów, konsolą systemową oraz lokalnym serwerem.

Czy idealne IDE istnieje? Tak. Jakie to IDE? Każdy odpowie, że to, z którego właśnie korzysta. I każdy będzie miał rację. Idealne IDE to taka aplikacja, z którą wygodnie się pracuje, a większość nudnych czynności wykonuje za nas.

Podczas pisania testów z wykorzystaniem PHPUnit często pojawia się zagadnienie związane z przekazywaniem zmiennych pomiędzy poszczególnymi testami. Załóżmy bowiem sytuację, gdy mamy test, w którym tworzymy sobie instancję jakiegoś obiektu i sprawdzamy działanie jednej z metod. W kolejnym teście chcemy przetestować kolejną z metod. Prześledźmy to może na przykładzie. Testowana klasa: Klasa testowa dla powyższej [...]

Ekran uruchamiania PHP Storm

Jest to pierwszy artykuł z serii „W poszukiwaniu optymalnego środowiska programistycznego„, w którym postaram się odpowiedzieć na pytanie czy istnieje IDE, które nie przeszkadza w codziennej pracy programisty i upraszcza najczęściej wykonywane operacje. Przeprowadzane testy polegały na pracy przez około 5 dni roboczych, w wybranym programie, nad tym samym projektem w celu zmarginalizowania przyzwyczajenia do mojego obecnego zintegrowanego środowiska programistycznego – Eclipse. Projekt składał się z kilku tysięcy linii kodu. Komputer na jakim pracowałem to 3 GB RAM, Intel Core 2 Duo T5500 i Windows 7 (Opcjonalne Mac OS X ale to w kwestii zrzutów ekranu z PHP Storm).

PHP Storm – zintegrowane środowisko programistyczne

Czym ma być PHP Storm, najlepiej mówią twórcy:

PhpStorm is a lightweight and smart PHP IDE focused on developer productivity that deeply understands your code, provides smart code completion, quick navigation and on-the-fly error checking. It is always ready to help you shape your code, run unit-tests or provide visual debugging.

Przekładając na język Polski:

PHP Storm to lekkie i mądre IDE dla PHP koncentrujące się na produktywności i zrozumieniu pisanego kodu. Oferuje podpowiadanie składni, szybką nawigację i sprawdzenie w locie błędów składni. Umożliwia szybkie udostępnianie kodu, testowanie kodu i wizualne debugowanie.

W tym artylule postaram się sprawdzić ile jest w tym prawdy. Zapraszam do lektury.

Tworzenie nowego projektu w PHP Storm

Pierwszym krokiem zaraz po instalacji IDE, która przebiegła bezproblemowo, było stworzenie nowego projektu. Operacja ograniczyła się do wybrania katalogu z projektem i poczekania kilku sekund aż IDE za-indeksuje pliki. Już na tym etapie, byłem pod wrażeniem szybkości i łatwości tej operacji (w Eclipse stworzenie projektu wymagało skorzystania z wizzardu i kilku kliknięć dalej, lecz też nie można powiedzieć że było to skomplikowane ale na pewno indeksowanie plików jest bardziej czasochłonne).

Ciekawym elementem jest to że podczas indeksacji mogłem pracować w projekcie praktycznie bez przeszkód. Jedynymi ograniczeniami był brak możliwości podpowiadania składni i wyszukiwania (Naturalnie w Eclipse też można pracować w trakcie indeksacji jednak to bardziej przypomina szarpankę niż pracę – subiektywne odczucie)

Po zindeksowaniu projektu przez PHP Storm zużycie pamięci było o ~250 MB mniejsze niż w przypadku Eclipse. Eclipse na starcie projektu potrzebuje ok ~550MB. Jest to ogromny plus dla PHP Storm, tym bardziej że w trakcie kilku godzinnej pracy ta wartość wzrasta dla tych IDE o kolejne ~200MB.

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

Zwiń
Czytaj na blogu autora...

Wstęp

Odpalimy naszą pierwszą aplikację i na jej podstawie powiem coś o strukturze katalogów, plikach i kodzie w nich zawartym – same podstawowe informacje o funkcjonowaniu Zenda. Na ich podstawie każdy powinien umieć uruchomić swoją pierwszą stronę opartą o Zend.

 Pobieramy Framweork

Pierwszą czynnością jaką musimy wykonać jest pobranie samego frameworka, możemy pobrać go tutaj, klikamy na wielki napis „Download New” i pobieramy interesującą nas paczkę, do wyboru mamy sam fw jak i z serverem lub dokumentacją. Jeśli nie chcemy żadnych dodatków klikamy na Zip lub tar.gz obok „Zend Framework 1.11.11 Minimal”, wersja oczywiście może się różnić od tej opisywanej tutaj.

Co dalej?

W paczce znajdziemy kilka folderów i plików, najważniejszym jest katalog library zawiera on wszystkie biblioteki Zend’a i na dobrą sprawę wystarczył by nam do wszystkiego, ale po co utrudniać sobie życie? Wrócimy do niego w dalszej części, katalog bin zawiera plik zf.bat dzięki niemu możemy wykonywać pewne operacje na naszej aplikacji nie odpalając naszego ide. Proponuję całą zawartość katalogu bin wrzucić do C:\Windows dzięki czemu korzystając w przyszłości z niego nie będziemy zmuszeni podawać całej ścieżki do pliku a tylko nazwę pliku zf.

Server

Jak pewnie wiecie (a jeśli nie, to czas przeczytać pierwszy wpis) aplikacje php potrzebują servera, tutaj jest kilka możliwości:

• Server w sieci
• Server na naszym Pc
• Gotowe rozwiązanie
• Ręczna instalacja

Osobiście polecam w etapie produkcyjnym rozwiązanie drugie, nie jest istotne czy zainstalujecie całą paczkę ręcznie czy użyjecie jakiejś gotowej. Jeśli nie masz jeszcze servera powinieneś się w niego zaopatrzyć. W dalszym etapie będę opisywać poczynania na maszynie lokalnej – tak jest wygodniej i oszczędzamy na opóźnieniach ftp.

Gdy mamy już server

Otwieramy konsolę cmd, standardowo znajdujemy się C:\User\nazwa_użytkownika używając komendy cd .. wychodzimy katalog do góry, a wpisując ścieżkę cd C:\Users\nazwa_użytkownika\Desktop dostaniemy się na pulpit (Windows 7) dla xp będzie to inna ścieżka – krótkie przypomnienie dla osób nie korzystających na codzie z konsoli.

Teraz możemy stworzyć nasz pierwszy projekt, wydajemy polecenie zf create project nazwa_projektu, jeśli wcześniej nie wkleiłeś pliku zf.bat do katalogu C:/Windows musisz podać pełną ścieżkę do pliku zf.bat np. C:/katalog/zf create project nazwa_projektu lub wejść do niego za pomocą komendy cd.

W oknie cmd powinniśmy dostać komunikat z ścieżką do nowo stworzonego projektu w moim przypadku jest to C:\Users\nazwa_użytkownika\Desktop\nazwa_projektu. Najlepiej wykonywać te operacje od razu w katalogu www naszego servera tym samym zaoszczędzimy sobie przenoszenia plików.

Co zawiera magiczny katalog nazwa_projektu

Zawartość katalogu nazwa_projektu powinna wyglądać tak:

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

Zwiń
Czytaj na blogu autora...

Było już o routingu. Tym razem, bez chwalenia się. Konkretny kod, konkretna funkcjonalność.

W momencie gdy nie odwołujemy się do konkretnego pliku na serwerze, np. wpisując adres w przeglądarkę: www.luxtorpeda.net, domyślnie ładowany jest plik, który został jako pierwszy wpisany w konfiguracji Apache’a zaraz po dyrektywie DirectoryIndex, np.

DirectoryIndex index.html index.php index.pl

W tym przykładzie jeśli istnieje plik index.html zostanie on wywołany, jeśli nie, zostanie wywołany index.php, jeśli ten również nie istnieje, index.pl.

Aby zmienić kolejność ładowania plików na serwerze, w przypadku gdy nie mamy dostępu do konfiguracji Apache’a wystarczy w danym katalogu umieścić plik .htaccess, w którym należy wpisać:

DirectoryIndex index.php index.html

W tym przypadku najpierw wywoływany będzie plik index.php, a potem index.html.

Duże aplikacje napisane w oparciu o Zend Framework zazwyczaj zawierają duży plik konfiguracyjny, niejednokrotnie zapisany w postaci XML. Im większy plik konfiguracyjny, tym wolniej jest on tłumaczony do postaci rozumianej przez PHP. Z tego właśnie względu warto zastosować cache’owanie konfiguracji naszej aplikacji.

Wbrew pozorom nie jest to proces skomplikowany i wymaga jedynie kosmetycznych poprawek w projekcie. Wystarczy utworzyć klasę dziedziczącą po Zend_Application, a w niej przesłonić metodę odpowiedzialną za wczytanie pliku konfiguracyjnego.

class Batman_Application extends Zend_Application
{
    /**
     * @var null|Zend_Cache_Core
     */
    private $_cache = null;

    /**
     * @param Zend_Cache_Core $cache
     */
    public function setCache(Zend_Cache_Core $cache)
    {
        $this->_cache = $cache;
    }

    /**
     * @return null|Zend_Cache_Core
     */
    public function getCache()
    {
        if($this->_cache === null) {
            $this->_cache = Zend_Cache::factory(
                'File',
                'File',
                array(
                    'master_files' => array(APPLICATION_PATH . '/configs/application.ini'),
                    'automatic_serialization' => true,
                    'lifetime' => null
                ),
                array(
                    'cache_dir' => APPLICATION_PATH . '/data/cache'
                )
            );
        }
        return $this->_cache;
    }

    protected function _loadConfig($file)
    {
        $cache = $this->getCache();
        $config = $cache->load('config_cache');
        if(!$config) {
            $config = parent::_loadConfig($file);
            $cache->save($config, 'config_cache');
        }

        return $config;
    }

Powyższy przykład korzysta z cache’u File, który automatycznie się odświeża, gdy w pliku konfiguracyjnym zostaną wprowadzone zmiany. Nic nie stoi na przeszkodzie aby to zmienić na dowolny inny cache, podobnie z resztą jak backend. Jeśli mamy dostęp do Memcached lub APC, o wiele lepiej będzie tam przechowywać cache, niż w pliku.

Jedyną zmianę jaką należy wprowadzić w już istniejącym kodzie, to modyfikacja pliku index.php, w którym zmieniamy nazwę klasy Zend_Application, na klasę przez nas utworzoną.

// reszta pliku index.php

require_once 'Zend/Application.php';
require_once 'Batman/Application.php';

// Create application, bootstrap, and run
$application = new Batman_Application(
    APPLICATION_ENV,
    APPLICATION_PATH . '/configs/application.ini'
);
$application->bootstrap()
            ->run();

Zanim jednak zdecydujemy się na cache’owanie konfiguracji, lepiej upewnić się, że taka zmiana nam się opłaci. Może się bowiem tak zdarzyć, iż parsowanie pliku z konfiguracją jest szybsze niż sprawdzenie czy cache jest aktualny.

Pliki z kodem źródłowym znajdziecie na Githubie.