porozmawiajmy o diagramach

Zdaję sobie sprawę, że pewnie wielu z Was odrzuca na samą myśl o UML-ach, ale chcąc nie chcąc, na pewnym etapie Waszej kariery się z nimi spotkacie i możliwe, że nawet sami będziecie musieli je wykorzystać do pracy twórczej. Dlaczego tylu programistów czuje awersję do diagramów? Cóż, przypuszczam, że wynika to z pewnej niechęci do tego, czego nie znamy, w tym konkretnym przypadku – do języka, który jest nam obcy. Bo tym właśnie jest UML, językiem, który nie wszyscy rozumiemy, którym nie wszyscy mówimy. Dzisiaj jednak nie o tym. Czytaj więcej »

W poprzednim wpisie opisałem technikę ataku SQL injection. W kolejnym artykule cyklu pokażę na czym polega równie popularny atak XSS i jak się przed nim uchronić. Trochę teorii Cross-site scripting (XSS) polega na osadzeniu w treści atakowanej strony kodu (zazwyczaj JavaScript), który wyświetlony przez innego użytkownika może doprowadzić do wykonania przez niego niepożądanych akcji. Jedną […]

In my recent project i had great opportunity to work together with powerful Symfony2 and amazing ExtJS5 frameworks. In the next few entries i will try to show you how to setup and configure Symfony2 application to serve REST API, than how to build ExtJS UI that will communicate with our REST API and finally how to setup basic authentication for REST API and ExtJS application… and maybe more.

Post RESTful ExtJS 5 and Symfony2 REST API: Symfony2 pojawił się poraz pierwszy w Kamil Adryjanek.

SQL injection jest techniką ataku starą jak świat. Mimo tego wciąż jest niestety dość powszechną i prostą metodą ataku na strony www (nawet na te największe jak portale). Dzieje się tak, ponieważ przy tej metodzie najsłabszym ogniwem jest programista. Zobacz na czym polega ten atak i jak się przed nim zabezpieczyć. Trochę teorii SQL injection […]

Na początku nakreślę problem. Mamy klasę Product oraz interfejs ProductRepository.

interface ProductRepository {  
    function save(Product $product);
    function delete(Product $product);
    function findOne($id);
    function findAll();
    //...
}

ProductRepository może mieć kilka implementacji, np.:

• DoctrineProductRepository - zapisywanie obiektów do bazy danych z wykorzystaniem EntityManagera z Doctrine, nasza "rzeczywista" implementacja używana przez aplikację
• InMemoryProductRepository - trzymanie obiektów w pamięci, klasa wykorzystywana np. do testów funkcjonalnych kontrolerów lub serwisów - nie chcemy angażować bazy danych aby testy były szybsze, prostsze do konfiguracji itp.

Obie implementacje muszą działać tak samo, tak więc powinny mieć taki sam zestaw testów.

Rozwiązanie problemu

Jednym z rozwiązań jest napisanie abstrakcyjnej klasy testu, testowany obiekt oraz tworzenie danych testowych są w formie metod abstrakcyjnych.

abstract class ProductRepositoryTest extends PHPUnit_Framework_TestCase {  
    protected $repository;

    protected function setUp() {
        $this->repository = $this->createSUT();
    }

    //tworzenie obiektu testowanego
    abstract protected function createSUT();

    //umieszczanie Produktu w źródle danych    
    abstract protected function insertProduct(Product $product);

    /**
     * @test
     */
    public function givenExistingProduct_whenItIsDeleted_thenProductCouldNotBeFound() {    
        //given        
        $product = new Product(...);
        $this->insertProduct($product);

        //when        
        $this->repository->delete($product);
        $actualProduct = $this->repository->findOne($product->getId());

        //then        
        $this->assertNull($actualProduct);
    }

    //...
}

W konkretnych podklasach nadpisujemy metody createSUT i insertProduct.

Jest jednak problem... Klasa testu operującego na rzeczywistej bazie danych niekoniecznie rozszerza bezpośrednio PHPUnit_Framework_TestCase. Klasa bazowa dla testów na bazie dostarcza tworzenie połączenia, obtacza testy w transakcję która na końcu jest rollbackowana itp. Tak więc występuje potrzeba wielodziedziczenia, DoctrineProductRepositoryTest powinien rozszerzać zarówno ProductRepositoryTest oraz DoctrineTestCase. Nie jest to możliwe, chyba że zamienimy ProductRepositoryTest w trait.

/**
 * @mixin \PHPUnit_Framework_TestCase
 */
trait ProductRepositoryTest {  
    //to samo co w klasie ProductRepositoryTest
    //w poprzednim listingu
}

Adnotacja @mixin jest interpretowana przez PhpStorm tak, jakby ProductRepositoryTest "rozszerzał" PHPUnit_Framework_TestCase, dzięki czemu poprawnie działa podpowiadanie metod (np. asercji).

Możemy zatem wykorzystać trait do stworzenia testu dla DoctrineProductRepository.

class DoctrineProductRepositoryTest extends DoctrineTestCase {  
    use ProductRepositoryTest;

    protected function createSUT() {
        return new DoctrineProductRepository($this->em);
    }

    protected function insertProduct(Product $product) {
        $this->em->persist($product);
        $this->em->flush();
    }
}

Podobnie by wyglądał InMemoryProductRepositoryTest. Gdy dopisujemy jakiś test do ProductRepositoryTest, automatycznie będzie on wykonywany dla dwóch różnych implementacji ProductRepository. Minusem tego rozwiązania może być zaburzenie pętli TDD. Pisząc jeden test tak naprawdę mamy w rezultacie dwa czerwone testy - czyli w następnym kroku musimy zaimplementować dwie funkcjonalności dla dwóch całkowicie różnych klas, aby na nowo mieć przed oczami tylko zieleń. Pętla "Red -> Green -> Refactor" zamienia się w "Red x2 -> Green, Red -> Green x 2 -> Refactor x 2". Można temu przeciwdziałać wstawiając test najpierw do DoctrineProductRepositoryTest, a po zaimplementowaniu funkcjonalności i refaktoryzacji, przenieść go do ProductRepositoryTest.

Mając na początku interfejs ProductRepository i pisząc pierwszą implementację (np. DoctrineProductRepository), nie powinniśmy zaczynać od razu od tworzenia cechy/klasy abstrakcyjnej ProductRepositoryTest, gdyż tak naprawdę nie wiemy czy ona będzie potrzebna. Metody testowe należy umieszczać bezpośrednio w DoctrineProductRepositoryTest, a gdy będziemy mieć drugą implementację ProductRepository, powinniśmy dokonać refaktoryzacji wydzielenia cechy (trait) bądź klasy.

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

Zwiń
Czytaj na blogu autora...

Czym jest pasek ładowania nie muszę chyba tłumaczyć :). Jest to bardzo przydatne narzędzie, gdy wczytujemy większą ilość danych co zabiera trochę czasu – dzięki temu użytkownik wie, że „coś” się dzieje. Pokażę tobie jak stworzyć taki pasek za pomocą dwóch klas CSS oraz jednej funkcji jQuery. Na początek stwórzmy szkielet dokumentu HTML: Zwróć uwagę […]

Początkowo chciałem zrobić standardowe podsumowanie ostatniej konferencji PHPCon Poland. Po chwili zastanowienia uznałem, że tak naprawdę PHPCon Poland wyznacza trendy na następny rok na naszym polskim rynku PHP.

W moim mniemaniu liczą się obecnie tylko 2 frameworki – Symfony 2 oraz Zend Framework 2. Cała reszta nie jest warta uwagi. Jeśli Twoim zdaniem Sf2 lub ZF2 są za duże na Twój projekt – wykorzystaj tylko poszczególne komponenty jakich dostarczają, albo napisz coś własnego małego… i użyj komponentów od dużych braci.

Jednym z powodów przejścia GoldenLine na Symfony było wsparcie jakie daje firma, która stoi za frameworkiem, znajomość frameworku przez rynek (programistów) oraz jego dojrzałość rozumiana przez pryzmat mnogości komponentów, gotowych elementów. To prawda, że są to wielkie kobyły, bez włączonego opcache ani rusz, ale taki jest rynek…

Z powodu wejścia tak sporych frameworków między innymi zmienia się PHP jaki znamy. Do jądra nie tylko dochodzą nowe bajery, ale również trwa ciągła optymalizacja wydajności i zarządzania zasobami.

HHVM

Odważniejsi mogą spróbować HHVM, który „zastąpił” HipHopa i staje się coraz bardziej dojrzały. W tym momencie już 27 narzędzi/frameworków da się w pełni uruchomić z wykorzystaniem HHVM (m.in. laravel, doctrine2, composer, phpunit, twig). Wystarczy PHP w wywołaniu zastąpić HHVM i nic więcej nie trzeba robić co pokazał Mariusz Gil.

HHVM przyspiesza composera ponad 5x. Czas wywołań testów na standardowym bench.php są oszałamiające, HHVM potrzebuje tylko 0,26 s, gdzie te same operacje PHP (5.5.9) bez żadnego wsparcia wykonywał przez 1,44 s. Ale najważniejszą kwestią jest architektura aplikacji, pomyślenie w odpowiednim momencie o cache’u, bazie danych, zewnętrznych API, czy odpowiednim zastosowaniu Redisa. Dopiero w takim momencie możemy pomyśleć o HHVM, czy czekać na PHP-NG, które będzie domyślnym silnikiem w PHP 7.0.

xhprof i aktualizacje

Ale po co w ogóle coś usprawniać? Badania pokazały, że jeśli coś trwa mniej niż 100 ms nasz mózg uważa że jest to natychmiastowa operacja. Zacznijmy optymalizować, jeśli żądania trwają powyżej 100 ms.

Wtedy można skorzystać z xhprof, młodszego, lepszego brata xdebug’a, z którego naprawdę prosto się korzysta i równie prosto instaluje (np. w połączeniu z xhgui). Należy również pamiętać o aktualizacjach samego PHP. Przejścia na PHP 5.6 jeszcze nie zalecam z powodu zbyt młodego wieku, ale najnowsza wersja PHP 5.5 to obowiązek. To nie tylko nowe możliwości (np. generatory, finally, password_hash), ale również zwiększona szybkość.

Testy jednostkowe

Żeby móc rozpocząć jakiekolwiek optymalizacje czy refactoring kodu należy posiadać najpierw w aplikacji testy jednostkowe. Podstawowym problem zawsze wydaje się na początku brak czasu i brak budżetu, ale jak kolejny raz podkreślił Michelangelo van Dam tak nie jest. Testy jednostkowe to same plusy:

• natychmiastowy feedback w przypadku błędu
• test piszemy raz, korzystamy z niego przy każdym wdrożeniu
• o wiele prościej dokonać zmian w kodzie (refactoring)
• prościej analizować kod aplikacji (debug)

Pisząc unit tests należy tylko pamiętać, aby testować jak najmniejsze jednostki kodu (smallest unit-of-code). Powinniśmy testować warunek po warunku (condition by condition), a nie do końca skupiać się na liniach kodu w metodzie. Testy powinny nam przetestować przede wszystkim logikę aplikacji, a nie same dane. Jeśli posiadamy integrację z zewnętrznymi API (np. płatności), również powinniśmy przetestować punkty styku, ewentualnie wirtualizując odpowiedzi drugiej strony.

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

Zwiń
Czytaj na blogu autora...