Najpopularniejszym językiem do tworzenia aplikacji internetowych jest niewątpliwie PHP. To w tym języku powstały najpopularniejsze fora, systemy blogów oraz cms-y. Mimo powolnego rozwoju, braku wyraźnych planów na przyszłość oraz mocno rozdrobnionej społeczności programistów i twórców, PHP zdołał utrzymać dominującą pozycję na rynku, a nawet przyciągnąć uwagę takich gigantów jak Microsoft.

Ostatnie kilka tygodni przyniosło wiele ciekawych informacji dotyczących samego języka oraz powiązanych z nim technologii. Powstało wiele narzędzi, światło dzienne ujrzały kolejne chmury dedykowane PHP, a sam język wkrótce czeka duża aktualizacja.

PHP 5.4

PHP w wersji 5 został wydany w roku 2004. Przez kolejne pięć lat niewiele się zmienił, aż do wydania wersji 5.3, która była małą rewolucją. Ekipa odpowiedzialna za język przyspieszyła prace, ponieważ już w 2011 roku pojawiła się beta kolejnej wersji PHP, oznaczonej numerem 5.4. Ze wszystkich wprowadzonych zmian najbardziej cieszą mnie:

• wbudowany serwer deweloperski,
• traits,
• <?= działający zawsze, niezależnie od ustawienia short_open_tag.

Pełną listę zmian pierwszej bety znajdziecie pod adresem http://www.php.net/releases/NEWS_5_4_0_beta1.txt.

Narzędzia

W dziedzinie narzędzi mamy wysyp aplikacji od IDE/edytorów począwszy, przez system “paczkujący”, na nowych frameworkach kończąc.

Zacznijmy od IDE/edytorów:

• Adobe Flash Builder for PHP – Adobe wraz z Zendem wypuściły IDE pozwalające tworzyć aplikacje, których frontend budowany jest we Fleksie, a backend w PHP. Miałem okazję brać udział w testach wersji pre release i szczerze przyznam, że narzędzie to robi wrażenie.
• WebMatrix 2 – druga wersja (jeszcze w fazie beta) narzędzia wydanego przez Microsoft, służącego do “bezkodowego” tworzenia aplikacji. Narzędzie powstało z myślą o ludziach niekoniecznie technicznych, ale wymagający użytkownicy również będą z niego zadowoleni. Spośród wielu wprowadzonych zmian, na uwagę zasługuje podpowiadanie składni PHP oraz niektórych aplikacji w nim stworzonych, np. WordPressa.
• PhpStorm 3 – wprawdzie jest to wersja EAP (Early Access Program), ale już teraz wiadomo jakie nowe funkcjonalności się pojawią. A będą to m.in. wbudowany profiler Xdebug, wykrywanie zduplikowanego kodu oraz tworzenie diagramów UML.
• Zend Studio 9 – również w fazie beta, znalazło się w zestawieniu ponieważ w połączeniu z chmurą Zenda (o czym za chwilę) powoduje, iż tworzenie aplikacji PHP, a następnie ich wdrażanie, jest bardziej niż proste.

Kolejną podkategorią narzędzi są frameworki. Tutaj tylko (albo aż) dwie pozycje:

• Symfony 2 – pisałem już na blogu o tym frameworku, więc nie będę się powtarzał. Napiszę jedynie, iż framework ten nie przypadł mi do gustu.
• Zend Framework 2 – mocno spóźniony i niedokończony, ale w końcu dostępny. Z pierwszych nieśmiałych prób korzystania z niego, można wywnioskować, że za kilka miesięcy będzie to dobry, jeśli nie najlepszy framework PHP. Jednak za porządne testowanie wezmę się dopiero wtedy, gdy wszystkie komponenty będą już przygotowane.

Wraz z premierą ZF2 pojawił się ciekawy projekt o nazwie ZF packages. Jest to system paczek możliwych do zainstalowania w naszej aplikacji przy pomocy pyrus, następcy pear. Daje to nadzieje na pojawienie się w PHP systemu paczek z prawdziwego zdarzenia. Dlaczego? Ponieważ pieczę na nimi będzie sprawowała firma od PHP i Zend Frameworka.

Chmura

Niezaprzeczalnym hitem ostatnich lat w dziedzinie hostowania aplikacji, jest chmura. Na tym polu PHP również dobrze się trzyma, zdobywając kolejne przyczółki.

• Windows Azure – tworzenie, wdrażanie oraz utrzymywanie aplikacji PHP w chmurze Microsoftu jest bardziej niż proste, co niejednokrotnie udowodnił Maarten Balliauw, twórca Windows Azure SDK dla języka PHP.
• PHPFog – chmura dedykowana językowi PHP, zbudowana w oparciu o infrastrukturę Amazona
• Azure+ – kolejna chmura dedykowana PHP. W odróżnieniu od PHPFog, została zbudowana na platformie Windows Azure.
• Zend Developer Cloud Platform – najmłodsza chmura dedykowana PHP wyszła spod igły firmy Zend i wszystko wskazuje na to, że będzie najlepszą pod względem możliwości chmurą dedykowaną temu językowi. Dzięki integracji z Zend Studio (od wersji 9), deploy aplikacji do chmury odbywa się automatycznie. Jeśli nie chcemy/nie możemy korzystać z Zend Studio, wówczas mamy możliwość wdrażania aplikacji przy pomocy Gita lub przy pomocy protokołu SFTP. Po przeprowadzeniu pierwszych testów jest pod ogromnym wrażeniem. Od momentu zalogowania się na konto, do utworzenia aplikacji opartej o Zend Framework upłynęło tylko kilka minut. Więcej czasu zajęło mi generowanie kluczy i konfigurowanie klienta Git.

Podsumowanie

Pojawiające się narzędzia i projekty bazujące na PHP pokazują, iż język zaczyna być postrzegany nie tylko w kontekście domowych stron oraz programistów “hello world”. Obawiam się, że kolejne projekty paradoksalnie pogorszą sprawę, wprowadzając jeszcze większą fragmentację świata PHP. Z drugiej jednak strony może dojść do sytuacji, w której rynek sam się oczyści i z chaosu frameworków, edytorów oraz innych narzędzi, wyłoni się garstka najlepszych, dla których reszta będzie nic nieznaczącym tłem.

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

Zwiń
Czytaj na blogu autora...

Generally, it’s not a good idea to unit test protected or private methods, but in some cases it could be useful. Of course we don’t want to change our class contract, and expose those methods as a public ones, just becasue we want to test them with PHPUnit. This case can’t be solved with Proxy-Object [...]

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:

• obsługa podstawowych tagów HTML oraz podstawowych stylów (składnia ustawiania stylów różni się od HTMLa, niektóre nazwy atrybutów również się różnią - szczegóły w dokumentacji dostępnej w repozytorium na githubie
• dokument źródłowy w formatach XML oraz Markdown
• obsługa arkuszy styli w formacie XML
• podstawowe funkcjonalności HTML (niektóre różnią się w zachowaniu): opływ elementów (float), wyrównanie tekstu (+ justrowanie), obramowanie, tła, marginesy, paddingi itp.
• odnośniki wewnętrzne (do elementów wewnątrz dokumentu) oraz zewnętrzne (url)
• obsługa czcionek ttf oraz wbudowanych
• automatycznie lub wymuszone łamanie strony, "niełamalne" elementy, powtarzalne nagłówki i stopki, numeracja stron
• podział strony na kolumny, automatyczne lub wymuszone łamanie kolumny
• obsługa zakładek i adnotacji
• obsługa złożonych znaków wodnych
• możliwość wykorzystania istniejącego dokumentu jako szablonu
• integracja z Symfony2 za pomocą bundla PdfBundle
• i w wiele innych ;)

Do czego ta biblioteka się nie nadaje:

• bezpośrednie konwertowanie kodu HTML do PDFa - są do tego zadania naprawdę świetne, lepsze biblioteki, np. program wkhtmltopdf. Poza tym PHPPdf nie jest kompatybilny z HTML'em, zadaniem tej biblioteki nie jest dostarczenie narzędzia zamieniającego kod HTML na PDFa.

Do czego ta biblioteka jest przeznaczona:

• tworzenia złożonych dokumentów pdf, nad których wyglądem, strukturą i układem powinniśmy mieć możliwie jak największą kontrolę, czego, ze względu na specyfikę formatu PDF i HTML, nie do końca zapewnia nam HTML oraz CSS, a tym samym biblioteki konwertujące kod HTML do PDF.

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.

Trochę teorii…

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:

• Model – jest pewną reprezentacją problemu bądź logiki aplikacji.
• Widok – opisuje, jak wyświetlić pewną część modelu w ramach interfejsu użytkownika.
• Kontroler – przyjmuje dane wejściowe od użytkownika i reaguje na jego poczynania, zarządzając aktualizacje modelu oraz odświeżenie widoków.

Brzmi strasznie, ale w praktyce okazuje się, że to wcale nie jest takie trudne …

No to zaczynamy!

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:

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

Zwiń
Czytaj na blogu autora...

Today I needed to add a custom class to textarea field, to achieve TinyMCE field rendering (with help of http://symfony2bundles.org/stfalcon/TinymceBundle). It wasn’t such straightforward like I thought… I tried: But it threw exception, that attribute „class” is undefined, so I need to solve it in other way. Thank god I use Twig, so I tried [...]

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.