Chwilę przed świętami ruszyła rejestracja na kolejną edycję (trzecią) 4Developers. Tym razem odbędzie się ona w Warszawie w dniu 4. kwietnia 2011.

Wzorem z poprzednich lat „pierwszy nabór” jest całkowicie w ciemno (brak agendy, prelegentów itp.), w zamian jeśli zarejestrujemy się do 1 stycznia 2011 roku zapłacimy za udział tylko 170 zł. Co w zamian? Wyłącznie marka PROIDEA, która wcześniej organizowała 4Developers czy JDD.

Konferencja 4Developers 2011 podzielona jest na 4 sesje:

• Java
• Zarządzanie projektami IT
• Wydajność i skalowalność
• PHP

W tym momencie zapisów nie musimy decydować się na konkretną sesję. Ja najchętniej poczekam do opublikowania całej agendy. Agenda PHP w zeszłym roku nie powalała, ale czego można oczekiwać od 8-godzinnej konferencji z 45 minutowymi prelekcjami. Natomiast cieszy mnie fakt oficjalnego zniknięcia z sesji „.Net & C#” (bez urazy), a wprowadzenie „Wydajność i skalowalność„.

Jeśli ktoś nie potrafi się zdecydować bez agendy, dodam że styczniowa cena nie jest już tak miła dla oka – 270 zł, ale na pewno w tym czasie pojawią się pierwsze informacje o tematach edycji 2011. Później będzie tylko gorzej:

• 382.00 PLN do 27 Lutego 2011
• 490.00 PLN do 27 Marca 2011
• 790.00 PLN Last MINUTE – do 4 Kwietnia 2011

Dlatego radziłbym decydować się jeszcze przed Sylwestrem. Ja już się zapisałem, 170 zł to nie majątek, a bardzo mnie cieszy że w tym roku 4Developers odbędzie się w Warszawie.

Rejestracja na 4Developers 2011

Kilka dni temu, Mathias Grimm, zgłosił na grupie php.internals propozycję dodania makr preprocesora do PHP. Miały by działać one analogicznie jak te w C, z wyjątkiem tego, że były by deklarowane za pomocą funkcji MACRO(‘nazwa_makra’,'jakas_tresc_makra’). Propozycja nie spotkała się raczej z entuzjastycznym przyjęciem. Oponenci argumentowali, że z racji na dynamiczną naturę języka dodanie makr nie wnosi żadnej nowej jakości i tylko zaciemnia kod dla osób nie zaznajomionych z nim. Wobec tego propozycja raczej nie przejdzie, chociaż widzę, że dyskusja się dość rozwinęła. Przy okazji tej dyskusji wyszło kilka ciekawych rzeczy, np. że jest rozszerzenie o nazwie „prep„, które tą obsługę wprowadza natywnie, oraz również mająca podobną funkcjonalność implementacja w czystym php. Z innych wartych odnotowania spraw, dowiedzieć się można, że używa się też gcc do takich rzeczy w formie:

<?php
#define PF private function
#define SCOPE_CLASS(x) class MyProject_ ## x

class UseMacro
{
     PF preSave($object)
     {
        //...
     }

}

SCOPE_CLASS(Internal)
{

}
?>

taki kod następnie należy przepuścić przez gcc komendą:

gcc -Mcpp -E - - < in.php > out.php

Widać kreatywność ludzka nie zna granic. Tak czy inaczej, ja osobiście uważam, że makra w php są zbędne, natomiast sądzę, że zamiast nich przydało by się wsparcie api dla rzeczy, które w tej chwili wykonuje się przy pomocy evala, np. anonimowe klasy, czy dynamiczne proxy.

Ciekaw jestem, jakie jest Wasze zdanie na ten temat ?

Mamy święta i dużo wolnego czasu, dlatego dzisiaj będziemy zajmować się modułem Zend Framework odpowiedzialnym za czas – Zend_Date. Proponuję przeczytać moje gryzmoły zamiast objadać się nadmiernie karpiem czy co tam macie. Dodatkowo zahaczymy o Zend_Config w postaci odczytu, modyfikacji i zapisu nowych danych do pliku .ini.

Będziemy robić moduł odpowiedzialny za automatyczne usuwanie dawno otwartych (a zatem niepotrzebnych) jakichś plików na serwerze. Mogłyby to być pliki miniaturek obrazków, które kiedyś nam system wygenerował i są już niepotrzebne.

Domyślnie każda aplikacja w ZF ma plik konfiguracyjny application.ini zapisany w /application/configs/. Dla naszych celów założymy sobie plik thumbs.ini, który będziemy mordować czytaj: ciągle nadpisywać. W pliku zapiszemy sobie 4 linijki:

[production]
cleanafter = "Dec 25, 2010 6:26:09 PM"
checkinterval = "5"
intervalunit = "MINUTE"

Wyraz w nawiasie oznacza środowisko, w którym pracujemy, cleanafter to data zapisana w formacie DATETIME. Checkinterval i intervalunit to zmienne służące nam do wygenerowania nowej daty cleanafter.

Kod, który podam poniżej można sobie zapisać w jakimś kontrolerze albo jako plugin.

// ważne jest ustawienie opcji 'allowModifications' na true,
// bo inaczej konfiguracja będzie w trybie tylko do odczytu
$config = new Zend_Config_Ini(ROOT_DIR.'/application/configs/thumbs.ini','production',
   array('allowModifications' => true));
// konstruujemy obiekt Zend_Date na podstawie danych z
// konfiguracji i podajemy format, w jakim dostarczymy dane nt. daty
$cleanAfter = new Zend_Date($config->cleanafter, Zend_Date::DATETIME);
// jeżeli nic nie podamy to Zend weźmie sobie datę i czas obecny
$currentDate = new Zend_Date();
// bardzo fajna funkcja isEarlier() porównująca daty
if ($cleanAfter->isEarlier($currentDate)) {
   echo 'coś robię';
   // wyznaczamy nową datę do wpisania do konfiguracji;
   // myślę, że sklonowanie obiektu daty powoduje trochę mniejszy
   // narzut zasobów niż tworzenie od nowa obiektu
   $newCleanDate = clone $currentDate;
   // dodajemy datę; funkcja add() ma 2 argumenty: ile dodać i co dodać;
   $newCleanDate->add(
      $config->checkinterval,
      constant('Zend_Date::' . $config->intervalunit)
      );
   // przypisujemy do configa datę w formacie DATETIME
   $config->cleanafter = $newCleanDate->get(Zend_Date::DATETIME);
   // tworzymy obiekt służący do zapisu configów
   $writer = new Zend_Config_Writer_Ini();
   $writer->setConfig($config);
   $writer->setFilename(ROOT_DIR.'/application/configs/thumbs.ini');
   $writer->write();
 
   // przygotowujemy obiekt daty, z którym będziemy
   // porównywać czas ostatniego otwarcia plików
   $deleteOlderThan = clone $currentDate;
   // add() dodawało, sub() odejmuje; my odejmiemy 1 tydzień
   $deleteOlderThan->sub(1, Zend_Date::WEEK);
   // tworzymy iterator podając katalog z miniaturkami do sprawdzenia
   $dirIterator = new DirectoryIterator(APPLICATION_PATH  . '/../public/thumbs');
   foreach ($dirIterator as $file) {
      // $getATime() podaje czas ostatniego otwarcia pliku
      // w formacie TIMESTAMP, z którego skonstruujemy datę
      $fileOpenDate = new Zend_Date($file->getATime(), Zend_Date::TIMESTAMP);
      // jeżeli data ostatniego otwarcia jest wcześniejsza
      // niż przyjęty przez nas limit 1 tygodnia to wywalamy plik
      // wygłuszając ewentualne komunikaty poprzez @
      if ($fileOpenDate->isEarlier($deleteOlderThan)) {
         @unlink($file->getRealPath());
      }
   }
}

Polecam zwrócić uwagę na constant(), który w locie na podstawie nazwy odwoła się do stałej obiektu. Konstrukcja typu ${'jakas' . $zmienna} prawidłowa dla zmiennych nie jest dostępna dla stałych i należy użyć funkcji constant().

A poza tym to Wesołych Świąt

Ekipa odpowiedzialna za Doctrine poinformowała o wydaniu pierwszej stabilnej wersji Doctrine 2. Spośród wszystkich zmian jakie zaszły w projekcie, najważniejszą zdaje się być brak kompatybilności z poprzednią wersją oraz fakt, iż Doctrine 2 działa tylko na PHP 5.3.

Pełną informację na temat zmian znajdziecie na blogu Doctrine. Zachęcam również do zapoznania się z tutorialem oraz dokumentacją.

Ostatnio z przypływu różnych myśli, zacząłem się zastanawiać nad własnym biznesem. Doszedłem do wniosku, że podstawą by odnieść sukces na polu tworzenia jakichkolwiek aplikacji www potrzebne jest posiadanie zestawu narzędzi/środków, dzięki którym będę mógł szybko i sprawnie tworzyć rozwiązania dla klientów. Potrzebny jest więc, framework obudowany własnymi bibliotekami albo kilka gotowych produktów open source, które trzeba będzie modyfikować do własnych potrzeb. Żeby podjąć jakąkolwiek decyzje w tej materii (wyboru rozwiązania) skonstatowałem, że najlepiej będzie zrobić charakterystykę kilku głównych typów aplikacji webowych.

Oto ona (należy kliknąć aby zobaczyć ją w 100% ponieważ niestety nie mieściła się na stronie):

I teraz krótkich kilka słów, co, dlaczego i po co ? Zacznijmy może od opisu poszczególnych kolumn:

• nazwa – przyjęta w branży nazwa charakteryzująca dany typ aplikacji www
• dostawca głównej treści – ta kolumna mówi nam, kto w głównej mierze tworzy „widoczną” treść serwisu
• sprawca działania – typ użytkownika, który głownie powoduje przepływ danych w serwisie
• skomplikowana logika biznesowa – dla wielu może trochę zagadkowa kolumna, mówi ona o tym, czy reguły wg których ma działać nasz kod są jednoznaczne i można je łatwo wtłoczyć w jakieś schematy czy też zawierają dużo wyjątków od głównej reguły i rozgałęzień sterowania
• nakład pracy przy kodowaniu – w pewnym stopniu wynika z poprzedniej kolumny, jest to nakład pracy potrzebny przy stworzeniu danego typu aplikacji od podstaw, ewentualnie przy użyciu popularnego frameworka
• flow – opisuje sposób przepływu zdarzeń na które reaguje aplikacja, zdarzenia mogą być przekazywane przez url, albo przez wywołania webservice’ów różnej maści
• poziomy uprawnień – opisuje jak bardzo aplikacja jest podzielona ze względu na poziomy dostępu użytkowników, czy można zaprojektować ją sztywno dzieląc ją na obszary do których użytkownicy mają dostęp, czy też poszczególne uprawnienia zależą od kontekstu roli użytkownika
• główny problem  - jest to najczęstszy i najdroższy problem, który zwykle pojawia się przy tworzeniu danego rodzaju aplikacji
• standartyzowalność – określa czy można w łatwy sposób stworzyć framework, czy system, dzięki któremu będzie można składać aplikację z „klocków”
• gotowe rozwiązania open source – zawiera informacje, czy istnieją już gotowe i darmowe systemy, których można użyć do tworzenia danego rodzaju aplikacji

Na pewno nie ująłem wszystkich typów aplikacji jakie istnieją. Jednak uważam, że ta tabela daje dobry ogólny pogląd na to, jak się sprawy na rynku mają. Trzeba wziąć też pod uwagę, że na rynku zdarzają się i będą coraz częściej zdarzać się aplikacje, które są miksem jednego lub kilku wymienionych rodzajów aplikacji. Patrząc na wymienione typy stron www nasuwa mi się taka konkluzja, że o ile komponenty potrzebne do budowania ich, w głównej mierze są dość wspólne (od strony widoku i może kontrolera) to każda będzie miała trochę inny charakterystyczny „workflow” działania. Myślę, że takie zestawienie jest dobrą szansą np. dla twórców wszelakich frameworków, które mają różnego rodzaju automatyczne generatory kodu, na przygotowanie kilku bazowych „profili” wg. których tworzona jest podstawowa struktura aplikacji.

Jestem bardzo ciekawy Waszych spostrzeżeń na ten temat, oraz tego czy macie może propozycje na inne rodzaje aplikacji www, i/lub kolumn w tym zestawieniu.

W poprzedniej części serii zaczęliśmy poznawać kontrolery w wydaniu ASP.NET MVC. Dzisiaj poznamy kolejne możliwości przez nie oferowane. Zaczniemy od filtrów, a dokładniej rzecz ujmując od filtra odpowiedzialnego za obsługę błędów.

Jeśli mieliście styczność z Zend Frameworkiem, na pewno waszej uwadze nie umknął kontroler o nawie Error, który uruchamiany jest za każdym razem, gdy w aplikacji źle się dzieje. W przypadku ASP.NET MVC nie ma domyślnego kontrolera, który obsługuje błędy. Obsługą błędów zajmuje się klasa HandleErrorAttribute. Niestety w przypadku PHP nie ma czegoś takiego jak atrybuty, więc z początku zapis filtrów może wydawać się dziwny. Gwarantuję jednak, że dają one ogromne możliwości.

Korzystanie z obsługi błędów należy rozpocząć od wprowadzenia modyfikacji do pliku konfiguracyjnego web.config. Domyślnie wyświetlanie błędów przy pomocy plików widoku działa na zdalnych maszynach. Innymi słowy my jako programiści widzimy wszystkie robaczki, a użytkownik końcowy tylko ładną informację o problemie. Aby to zmienić w sekcji system.web pliku web.config należy umieścić następujący kod:

<customErrors mode="On"></customErrors>

Jest to najprostsza forma jaką można dodać do pliku konfiguracyjnego. W wersji bardziej rozbudowanej mamy możliwość określenia do jakiego pliku nastąpi przekierowanie w przypadku wystąpienia konkretnego statusu błędu (o pliku web.config napiszę osobny wpis)

Teraz jeśli dodamy do klasy kontrolera filtr [HandleError], nasza aplikacja będzie w stanie wykryć nieobsłużone wyjątki i wyświetlić przygotowany przez nas komunikat błędu. Przykładowy kod kontrolera:

namespace MvcApplication1.Controllers
{
    [HandleError]
    public class HomeController : Controller
    {
        public ActionResult Index()
        {
            return View();
        }
    }
}

Filtr [HandleError] przechwytuje wyjątki i wyświetla widok Error z bieżącego kontrolera (w tym przypadku z kontrolera Home). Jeśli widok nie zostanie odnaleziony, kolejnym przeszukiwanym folderem będzie Shared.

Domyślnym zachowaniem filtra [HandleError] jest przechwytywanie wszystkich wyjątków jakie pojawią się w aplikacji. A co jeśli chcielibyśmy wyświetlać różne komunikaty błędów w zależności od rodzaju wyjątku? Nic prostszego. Wystarczy ustawić właściwości odpowiedzialne za przechwytywanie wyjątków i zwracanie widoku.

Właściwościami tymi są:

• ExceptionType – rodzaj przechwytywanego wyjątku
• View – widok, który zostanie wyrenderowany
• Master – szablon strony wzorcowej
• Order – kolejność z jaką filtry są stosowane

Prosty przykład przechwytywania konkretnego wyjątku oraz wyświetlenie komunikatu błędu innego niż domyślny:

[HandleError(ExceptionType = typeof(IndexOutOfRangeException), View = "AnotherError")]

W przypadku przechwytywania kilku różnych wyjątków należy pamiętać, że filtry dopasowywane są od góry i w momencie napotkania filtra, który może dany wyjątek obsłużyć, dalsze sprawdzanie filtrów zostaje przerwane. Dlatego ważne jest w takich sytuacjach umieszczanie najbardziej szczegółowych filtrów jak najwyżej

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

Zwiń
Czytaj na blogu autora...

Niestety burzliwa końcówka studiów oraz praca uniemożliwia mi zajęcie się Open Power Template'm od strony organizacyjnej, tj. pakowanie tego wszystkiego i wydawanie nowych wersji, jednak prace nad tym systemem cały czas trwają dzięki sprytnemu wykorzystaniu go w moim projekcie inżynierskim. Wersja 2.1 została mocno zdebugowana w ostatnich miesiącach, a dziś chciałbym bliżej przedstawić jedną z nowości, o które prosili mnie użytkownicy, czyli argumenty snippetów.