Ukończyłem pierwszą wersję PHPPdf o której pisałem kilka dobrych miesięcy temu, przy okazji zaliczając nieznaczny poślizg z terminem ;) Główne cechy biblioteki:
Do czego ta biblioteka się nie nadaje:
Do czego ta biblioteka jest przeznaczona:
Projekt jest hostowany na githubie. Dokumentacja w języku polskim oraz angielskim znajduje się w odpowiednich plikach README, przykładowe dokumenty znajdują się we folderze "examples" (należy uruchomić plik index.php z przeglądarki lub cli.php z konsoli). Bundle integrujące PHPPdf z Symfony2 znajduje się również na githubie.
Biblioteka działa na wersji php 5.3+, obecnie korzysta z Zend_Pdf, jednakże w przyszłości może to ulec zmianie.
Kolejny quiz ze stajni Nettuts+ dotyczy znajomości HTML5. Trudny nie jest, ale kilka pytań może sprawić problem. Popełniłem dwa błędy (uczciwie przyznaję, iż nie znałem odpowiedzi na te pytania) i uzyskałem tym samym wynik 88.89%. A wam jak poszło?
pobierz w .pdf(przeznaczone do wydruku)
Tworząc różnego rodzaju aplikacje natrafiamy na poważny problem utrzymania dobrej organizacji kodu – przejrzystej oraz łatwej w rozbudowie. Z pomocą przychodzą nam wzorce projektowe, które wymuszają na nas pewną organizację kodu aplikacji. W świecie aplikacji www najbardziej popularny jest wzorzec MVC. Jego ideę pokażę w praktyce – pisząc prosty system artykułów.
Żeby w pełni zrozumieć ideę tego wzorca projektowego czytelnik musi mieć solidne podstawy znajomości PHP oraz potafić programować obiektowo.
Model-View-Controller został zaprojektowany w 1979 roku przez norweskiego programistę Trygve Reenskaug pracującego wtedy nad językiem Smalltalk w laboratoriach Xerox i początkowo nosił nazwę Model-View-Editor.
Ideą tego wzorca jest rozdzielenie kodu odpowiedzialnego za przetworzenie danych od kodu odpowiedzialnego za ich wyświetlanie.
Model-View-Controller zakłada podział aplikacji na trzy główne części:
Brzmi strasznie, ale w praktyce okazuje się, że to wcale nie jest takie trudne …
Na samym początku stwórzmy szkielet katalogów:
config/ controller/ model/ view/ templates/
Mając hierarchię katalogów stwórzmy szkielet plików wzorca MVC:
Dewelopment w Javie fundamentalnie różni się od flow do którego jesteśmy przyzwyczajeni w przypadku aplikacji Pehapowych. Wynika to przede wszystkim z samej „natury” obu platform – PHP jest językiem interpretowanym, natomiast Java kompilowanym. Wobec tego, tworzenie, czy zmiana kodu wygląda zupełnie inaczej.
Jeżeli bym miał podsumować jednym słowem tworzenie kodu w PHP, to tym słowem było by „var_dump”. Pisząc jakiś kod, jesteśmy przyzwyczajeni do tego, że możemy go w każdej chwili zmodyfikować a potem sprawdzić efekty jego działania przy pomocy przywołanej wcześniej metody. Oczywiście są osoby, które w tym celu używają debuggera, jednakże jak wszyscy wiemy, są problemy z jego integracją z różnorakimi IDE i generalnie „var_dump” wydaje się być dość uniwersalnym narzędziem.
Pisząc w Javie, var_dump jest pierwszym z naszych pehapowych przyzwyczajeń, które powinniśmy schować do szuflady. Po pierwsze dlatego, że nie ma odpowiednika takiej funkcji w Javie, a po drugie dlatego, że var_dump driven development nie ma tam żadnych sensownych racji bytu. Dzieje się tak ze względu na czas jaki zajmuje deployment kodu – każda zmiana, jaką wprowadzimy w kodzie Javowym wymaga rekompilacji zmienionych klas i restartu serwera, co może trwać dość długo (np. w moim projekcie taka operacja trwa mniej więcej około 5 minut). Powstały oczywiście pewne solucje by temu zaradzić, takie jak np. podmienianie klas w trakcie działania serwera (Hot Swap), jednakże nie działają one we wszystkich przypadkach (jak dodanie, bądź usunięcie metody jakieś klasy).
Jak więc sobie radzić w takich warunkach ? Po pierwsze, musimy się zaprzyjaźnić z debuggerem. Wkrótce stanie się on naszym najlepszym przyjacielem, na którym będziemy polegać w każdej sytuacji. Debugger jest standardowo wbudowany w każde Javowe IDE, więc nie będziemy mieli żadnych problemów w korzystaniu z niego. Możliwości debuggera są naprawdę potężne i zaczynają się od przechodzenia kodu krok po kroku i podglądania wartości zmiennych, aż po zmianę ich wartości w locie oraz „cofanie się wstecz” w wykonaniu kodu.
Debuggera oczywiście najczęściej będziemy używać przy okazji poprawiania błędów. Jak natomiast sprawa się ma przy tworzeniu nowego kodu ? Tutaj z pomocą przychodzi nam dobrze znana, również z świata PHP technika Test Driven Development. Stosując TDD w kombinacji z debuggerem możemy dość skutecznie i szybko rozwijać nasz kod. Przy czym generalnie obowiązuje zasada, by raczej napisać jak najwięcej kodu przed jego testowaniem – nawet kompilacja testu, mimo, że jest to bardzo mała ilość kodu w porównaniu do całej aplikacji, którą depoloyujemy na serwerze nie jest natychmiastowa i chwilkę trwa. Jeżeli w tej chwili wyobraziliście sobie, że kompilujecie test tylko po to, żeby okazało się, że z jakiś głupich powodów nie działa, to mam dla Was dobrą informacje – dzięki statycznej naturze Javy, wszystkie „głupie” błędy zwykle podkreśli Wam na czerwono Wasz edytor, albo ostatecznie kompilator w momencie kompilacji.
Na koniec jeszcze taka mała uwaga odnośnie plików Javascriptowych. Zwykle bywa tak, że pliki źródłowe JS są częścią naszego Javowego projektu, w konsekwencji one również deployowane są na serwer wraz ze skompilowanymi klasamy Javy. W rezultacie, każda zmiana plików JS wymaga ponownego deployu projektu oraz restartu serwera co jak już wiemy – trwa dość długo. Na szczęście jak zwykle są na to sposoby 
. Po pierwsze, jeżeli tylko chcemy zmienić coś w JS do celów testowych, to wieść gminna niesie, że narzędzia deweloperskie Chrome’a pozwalają zmieniać Javascript „w locie”. Po drugie, w przypadku InteliJ Idea, istnieje opcja „update resources”, która podmienia tylko obrazki, js i inne tego typu pliki dość szybko, bez potrzeby restartu serwera.
Tym radosnym akcentem kończę ten artykuł i ogłaszam, że jest to już ostatni wpis z serii „Kierunek Babilon”, oczywiście dalej zamierzam pisać o PHP i Javie, ale już w trochę innym kontekście.
Kanał ATOM
