Pojawiła się nowa wersja PHPPdf oznaczona numerkiem 1.1.0, której główną zmianą jest silnik renderujący pliki graficzne. Lista zmian jest dostępna w changelogu, a opis nowych funkcjonalności w dokumentacji.
czytaj całość, komentarzy: 4
Pojawiła się nowa wersja PHPPdf oznaczona numerkiem 1.1.0, której główną zmianą jest silnik renderujący pliki graficzne. Lista zmian jest dostępna w changelogu, a opis nowych funkcjonalności w dokumentacji.
czytaj całość, komentarzy: 4
Często jest tak, że wydajność nie jest naszym absolutnym priorytetem, ale nie raz staje się ważna gdy faktycznie pod tym względem popełniliśmy zbyt wiele zaniedbań. Równie często zdarza się sytuacja, w której jednym z kluczowych wymagań niefunkcjonalnych jest właśnie odpowiednia wydajność. Optymalizacje można dokonywać po stronie serwerów (architektura, konfiguracja serwera, bazy danych itp.) oraz po stronie samej aplikacji (keszowanie dodatkowych elementów, trzymanie cache w pamięci operacyjnej, refaktoryzacja i optymalizacja kodu). W tym krótkim wpisie skoncentruję się na optymalizacji na poziomie kodu aplikacji.
czytaj całość, komentarzy: 6
Ukończyłem pierwszą wersję PHPPdf o której pisałem kilka dobrych miesięcy temu ;) Biblioteka służy do generowania dokumentu PDF z pliku źródłowego w formacie XML.
czytaj całość, komentarzy: 2
Od kilku miesięcy po cichu tworzę nową bibliotekę do generowania dokumentów pdf napisaną w php. Planowałem, że pierwsza w pełni funkcjonalna wersja wyjdzie w pierwszym kwartale 2011, jednak tego terminu na pewno nie dotrzymam ;) Jest jeszcze dosyć dużo do zrobienia, aby nadawała się do bezstresowego użycia.
czytaj całość, komentarzy: 6
Jedną z najbardziej podstawowych zasad programowania zorientowanego na obiekty to hermetyzacja danych. Mechanizmy php dostarczają nam modyfikatory dostępu, które to pomagają nam w hermetyzowaniu danych i implementacji poszczególnych klas, tak abyśmy mieli swobodę we wprowadzania zmian, które nie zmieniają funkcjonalności. API to interfejs, który nie ukrywamy, a udostępniamy. Co więc składa się na ten interfejs?
Na API klasy składają się:
czytaj całość, komentarzy: 4
Testy jednostkowe, jak sama nazwa wskazuje, polegają na testowaniu jednostki - jednego obiektu w ramach jednego zestawu testów. Co jednak w sytuacji, gdy testowany obiekt jest zależny od innego obiektu? Przy bezpośrednim wykorzystaniu tego dodatkowego obiektu w testach jednostkowych jest łamana podstawowa ich zasada. Przy wykorzystaniu rzeczywistego obiektu pomocniczego, robimy ślepe założenie, że działa on prawidłowo i nie zakłóci on wyników testów. Innymi słowy testy mogą się nie powieść, ale nie oznacza to jednoznacznie, że to w testowanej klasie jest błąd. Sytuacja może się również paradoksalnie odwrócić, testy zostaną przeprowadzone prawidłowo, mimo iż testowana klasa zawiera błędy, które powinny zostać wykryte.
Jakiś czas temu pracowałem nad projektem, którego funkcjonalności były oparte na wykorzystywaniu usług sieciowych o podobnej funkcjonalności. Pierwszym krokiem było ujednolicenie interfejsów tych usług. Na podstawie jednej z usług tworzyłem prosty interfejs, który później zaimplementowałem również dla pozostałych. Pierwszym krokiem było zastosowanie wzorca Facade, aby uprościć na potrzeby aplikacji interfejs pierwszej usługi sieciowej. Następnie pozostałe usługi sieciowe również zaadaptowałem do tego nowego interfejsu, wykorzystując wzorzec Adapter. Adapter od Facade różni się tym, że adapter przystosowuje zewnętrzny obiekt (zbiór obiektów) o podobnym interfejsie do już istniejącego, a fasada obudowuje złożony interfejs nowym, prostszym w użyciu. Ten wpis nie jest jednak o Adapterze (pisałem już o nim tutaj), ani o Facade, a o Service Stub.