Co jakiś czas zachodzi potrzeba wyszarzenia strony w związku z żałobą. Zazwyczaj podmienia się w tym celu grafikę na czarnobiałą lub w przypadku przeglądarki Internet Explorer stosuje się odpowiedni filtr. Niestety nie ma jednej prostej metody, która zadziałałaby od razu bez konieczności wykonywania dodatkowych czynności. A raczej nie było. W bezkresie Internetu znalazłem ciekawą bibliotekę Javascript, która za jednym zamachem załatwia problem wyszarzenia strony we wszystkich popularnych przeglądarkach.

Biblioteką tą jest grayscale. Zasada działania jest prosta. W przypadku IE stosowany jest filtr, dla wszystkich pozostałych przeglądarek canvas. Użycie grayscale jest banalnie proste i sprowadza się do wywołania jednej funkcji na elemencie, który chcemy wyszarzyć (przykład ze strony autora).

var el = document.getElementById( 'myEl' );
grayscale( el );
 
// Alternatively, pass a DOM collection
// (all elements will get "grayscaled")
grayscale( document.getElementsByTagName('div') );
 
// Even works with jQuery collections:
grayscale( $('div') );

Przykład działania znajdziecie w demo przygotowanym przez autora biblioteki.

Na koniec drobna uwaga. Grayscale mieli obrazki piksel po pikselu, a co za tym idzie będzie działał bardzo wolno w przypadku stron przeładowanych grafiką. Korzystajcie z tego rozwiązania z rozwagą.

W poprzednim wpisie poświęconym przechowywaniu danych w chmurze Windows Azure, opisałem czym są bloby oraz jak z nich korzystać. Dzisiaj skupimy się na drugim mechanizmie służącym do przechowywania danych w chmurze – kolejkom. Wbrew pozorom nie jest to błahy temat, ponieważ dzięki kolejkom właśnie mamy możliwość tworzyć aplikacje, które ze sobą rozmawiają.

Czym są kolejki?

Jak sama nazwa wskazuje, kolejki są mechanizmem przechowującym dane w… kolejce FIFO (z pewnymi odstępstwami, ale o tym za chwilę). Innymi słowy informacja zapisana do kolejki zostanie obsłużona w momencie, gdy wszystkie informacje dodane wcześniej zostaną obsłużone.

Zastanawiacie się pewnie po co takie mechanizm? Odpowiedź jest prosta. Aplikacje w chmurze nie są monolitem, który wie wszystko o wszystkim. Aplikacje są podzielone na mniejsze bloki, które nie muszą nic wiedzieć o pozostałych blokach. Takie rozproszenie funkcjonalności wymaga, aby bloki (a dokładniej role – o rolach napiszę osobny wpis) mogły komunikować się między sobą. I tutaj z pomocą przychodzą kolejki. Jeden blok otrzymuje dane, które należy przetworzyć. Ponieważ może zająć to dużo czasu, oddelegowuje tą czynność do odpowiedniego bloku, który zajmuje się tym zadaniem, a sam kontynuuje pracę. Najlepiej będzie pokazać to na przykładzie.Załóżmy, że mamy w chmurze aplikację www – galeria zdjęć. Do każdego zdjęcia, które doda użytkownik, tworzone są miniaturki oraz dodawany jest znak wodny. Co więcej, dodawane zdjęcia są w wysokiej rozdzielczości. W klasycznym modelu, tworzenie miniaturek oraz dodanie znaku wodnego odbędzie się tuż po dodaniu zdjęcia, co spowoduje chwilowy brak dostępu do serwisu do czasu, aż zdjęcie zostanie “przemielone”. W chmurze można zrobić to następująco. Użytkownik dodaje zdjęcie, rola web informuje przy pomocy kolejki rolę worker, że pojawiło się zdjęcie abc.jpg i “wraca” do użytkownika, który może kontynuować pracę. Rola worker mieli obrazek i może, ale nie musi poinformować (również przy pomocy kolejki) o zakończeniu pracy.

Jak to wygląda w praktyce?

Kolejki są jeszcze prostsze w użyciu niż bloby. W zasadzie korzystanie z nich sprowadza się do kilku prostych funkcji. Zacznijmy od utworzenia kolejki.

require_once 'Microsoft/WindowsAzure/Storage/Queue.php';
$client = new Microsoft_WindowsAzure_Storage_Queue();
$queue = $client->createQueue('kolejka');

var_dump($queue);

Powyższy kod wyświetli

object(Microsoft_WindowsAzure_Storage_QueueInstance)#7 (1) {
  ["_data:protected"]=>
  array(3) {
    ["name"]=>
    string(7) "kolejka"
    ["metadata"]=>
    array(0) {
    }
    ["approximatemessagecount"]=>
    int(0)
  }
}

Do tak przygotowanej kolejki można już dodawać wiadomości.

$client->putMessage('kolejka', 'do it!', 120);

Pierwszym argumentem funkcji jest nazwa kolejki, do której dodawana jest wiadomość, drugim argumentem jest treść wiadomości (maksymalnie 8KB), ostatnim czas życia wiadomości w sekundach. Parametr ten jest opcjonalny i domyślnie ustawiony na maksymalny możliwy czas, czyli 7 dni. Wiadomości po osiągnięciu tego czasu są usuwane z kolejki. Jest to o tyle ważne, że w przypadku problemu z jakąś wiadomością, nie zablokuje ona aplikacji na stałe, tylko na czas życia konkretnej wiadomości.

Kolejkę można przeglądać na dwa sposoby: pobrać wiadomości do obsługi lub podejrzeć wiadomości. Pobranie wiadomości oznacza, że wiadomość jest oznaczana w kolejce jako obsługiwana, dzięki czemu nie będzie miała miejsca sytuacja, w której jedną wiadomość obsługuje kilka ról na raz. Domyślnie wiadomość oznaczana jest jako obsługiwana na czas 30 sekund. Można ten czas zwiększyć maksymalnie do 2 godzin. Po jego upłynięciu, wiadomość wraca do kolejki na swoje miejsce (a dokładniej rzecz biorąc, staje się ponownie widoczna w kolejce). I przez to właśnie, kolejki w Windows Azure nie są prawdziwymi kolejkami FIFO.

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

Zwiń
Czytaj na blogu autora...

W jednym z ostatnich wpisów na internalsach, Loon var Reinier zgłosił propozycje RFC pt. ‘__autodefine’. Postuluje ona generalizację mechanizmu autoloadera i rozszerzenie go również m.in o funkcje, stałe i przestrzenie nazw.  Polegałby on na zdefiniowaniu funkcji __autodefine o parametrach ($nazwa, $typ), gdzie $nazwa to nazwa brakującego elementu, natomiast $typ to jedna ze stałych w rodzaju T_FUNCTION, T_CONST etc. Jako uzupełnienie funkcji __autodefine proponowane jest dodanie również funkcji spl_autodefine_register o działaniu analogicznym do spl_autoload_register.

Osobiście uważam, że pomysł jest dobry i przydatny. Jestem tylko zdania, że zarówno mechanizm autoload jak i autodefine powinien być używany tylko per przestrzeń nazw, aby uniknąć konfliktów.

A wy co o tym sądzicie :> ?

Ostatnimi czasy tworząc projekty coraz częściej zwracam uwagę na usability, poprawiając przy tym grafików. Dziś krótko, bo o tym, jak dostosować nagłówki <meta>, aby jak najlepiej były przeklejane do okienka udostępniania linków na Facebook’u.

Czasem cennymi danymi są te, które widzi Google oraz użytkownik (meta description i bezpośrednio w pasku przeglądarki title), czasem zależy nam na dostosowaniu prezentacji danych agregatorów, w naszym przypadku Facebook’a, aby użytkownik wklejając linka nie musiał się dodatkowo w nic angażować.

1. Wykryj, czy odwiedza Cię Facebook

   if(preg_match('/^facebookexternalhit/', $_SERVER['HTTP_USER_AGENT']))

2. Dostosuj swój meta description. Pamiętaj, że Facebook ucina spore części tekstów, dlatego sprecyzuj najbardziej chwytliwe fragmenty contentu, które mogą przyciągnąć użytkownika. Dodatkowo możesz zmodyfikować title dodając do niego dziwne znaczki (encje), które na pewno przyciągną wzrok.
3. Przygotuj odpowiedni obraz o odpowiedniej rozdzielczości, a następnie zaserwuj go w tagu: <link rel="image_src" href=" ... " /> Gdy tego nie zrobisz, użytkownik, który przekleja linka będzie sam musiał zdecydować o obrazie, który zostanie mu zaproponowany z puli dostępnych na stronie. Ta praktyka na szczęście jest często wykorzystywana przez programistów, wydaje się być trywialna.
4. Jeżeli chcesz wyeksponować ramkę Facebook’a na swoją stronę www, ustaw transparentność na iframe. Wbuduj ją w diva i nie zapominaj o możliwościach CSS takich jak position: absolute; position: relative; top: -1px; left: -1px; overflow: hidden; aby ukryć czasem kłopotliwe obramowanie iframe’a.

Efekt? Sprawdź sam na Nowiny365.pl.

Dzisiaj będzie coś dla wielbicieli Zend Frameworka. A dokładniej coś, z czym mamy do czynienia przetwarzając jakikolwiek formularz, czyli walidatory. Walidacja, a więc sprawdzanie czy wprowadzone przez użytkownika dane odpowiadają pewnemu schematowi jest obok filtracji, czyli wyrzucaniu zbędnych/niebezpiecznych rzeczy z danych chyba najważniejszą sprawą przy tworzeniu witryn WWW.

Zend Framework dysponuje zestawem kilkudziesięciu walidatorów, które można łączyć w łańcuchy przy walidowaniu poszczególnych pól formularza, np. pytając o wiek użytkownika pole musi zawierać wyłącznie liczby, czyli aż prosi się o Zend_Validate_Digits, a następnie należy sprawdzić czy podana liczba znajduje się w jakimś ludzkim przedziale, tzn. powiedzmy pomiędzy 1 a 100, co załatwi za nas Zend_Validate_Between.

Co w przypadku jeżeli musimy dopasowywać coś, czego nie przewidzieli twórcy ZF? Możemy napisać własny walidator.

Każdy walidator musi implementować interfejs Zend_Validate_Interface, czyli dwie publiczne metody:

• isValid($value) — zwracająca buliona prawda/fałsz
• getMessages() — zwracająca tablicę komunikatów co jest nie tak z wartością testowaną w isValid(). Komunikaty zwracane są w postaci kod_błędu => komunikat_w_ludzkiej_formie

W celu uniknięcia babrania się obsługą błędów i komunikatów twórcy ZF stworzyli abstrakcyjną klasę Zend_Validate_Abstract, która zrobi za nas większość brudnej roboty. Pozostanie nam tylko napisanie właściwej logiki co ma być sprawdzane i ewentualnie jaki błąd zgłaszany.

Na potrzeby swojej aplikacji napisałem własny w miarę uniwersalny walidator, który sprawdzi czy klucz podstawowy danej tablicy istnieje. Może mieć zastosowanie jeżeli ktoś sprawdza czy np. identyfikator wybranej przez użytkownika kategorii istnieje w bazie.

Poniżej przedstawiem kod z objaśnieniami po co coś jest. Po przeczytaniu stwierdzicie, że pisanie walidatorów to fajna zabawa

<?php
// rozszerzamy klasę abstrakcyjną dla walidatorów
class Spiechu_Validators_IsIdExists extends Zend_Validate_Abstract {     
 
  // definiujemy kody błędów i jakieś wartości dla nich
  const IDNOTEXISTS = 'idnotexists';
  const EMPTYSTRING = 'emptystring';
  const NULLVALUE = 'nullvalue';
 
  // definiujemy tablicę komunikatów błędów dla poszczególnych kodów
  // zwracam uwagę na '%value', które może być w locie zamienione na sprawdzaną wartość
  protected $_messageTemplates = array(
    self::IDNOTEXISTS   => "id '%value%' not exists",
    self::EMPTYSTRING  => 'given value is empty',
    self::NULLVALUE     => 'given value is null'
  );
 
  // zmienna typu Zend_Db_Table_Abstract, której klucz będziemy testować
  protected $_table;
 
  public function __construct(Zend_Db_Table_Abstract $table) {
    $this->_table = $table;
  }
 
  public function isValid($value) {
 
    // sprawdzamy czy zmienna nie jest nulem, a jeżeli tak to ustawiamy błąd
    if ($value === null) {
      $this->_error(self::NULLVALUE);
      return false;
    }
 
    // to samo dla pustego stringa
    if ($value === '') {
      $this->_error(self::EMPTYSTRING);
      return false;
    }
 
    $value = (int) $value;
 
    // ustawiamy wartość dla ewentualnego komunikatu %value%
    $this->_setValue($value);
 
    // metoda find szuka po kluczu podstawowym i zwraca rowset wyników
    $foundRows = $this->_table->find($value);
 
    // jeżeli nic nie znaleziono tzn. że sprawdzany klucz nie istenieje w tabeli bazy
    if (count($foundRows) == 0) {
      $this->_error(self::IDNOTEXISTS);
      return false;
    }
    else {
      return true;
    }
  }
}

Wszystko działa na tyle automagicznie, że tworząc jakiś element formularza wystarczy dodać stworzony walidator np. tak:

$formElement = new Zend_Form_Element_Select('pole_formularza');
$formElement->setRequired(true)
  ->setLabel('Jakaś etykieta')
  ->setMultiOptions($dane_do_wyboru)
  ->addValidator(new Spiechu_Validators_IsIdExists(new Sprawdzana_Tabela()));

Pluginów jQuery, których zadaniem jest wyświetlanie kolejnych zdjęć w postaci karuzeli (slidera) jest mnóstwo. Sam nawet popełniłem jedną karuzelę na własne potrzeby. Ostatnio wpadł mi w ręce kolejny plugin oferujący wspomnianą funkcjonalność i po pierwszych testach muszę przyznać, iż spełnia wszystkie moje potrzeby. Wprawdzie nie miałem jeszcze okazji skorzystać z niego w środowisku produkcyjnym, jednak nieśmiało można założyć, iż nie powinno być z nim większych problemów.

Slides, bo o nim mowa, został dokładnie przemyślany i oferuje szereg niezbędnych funkcjonalności. Do najpotrzebniejszych/najciekawszych można zaliczyć:

• możliwość ustawienia loadera dla elementów w karuzeli
• możliwość określania elementu, od którego rozpoczynać się będzie karuzela
• możliwość określenia efektu przejścia (na razie jest to tylko slide lub fade)
• możliwość losowego wyświetlania elementów

Nie są to jedyne możliwości oferowane przez Slides. Pełną ich listę, jak również przykłady i pliki do pobrania znajdziecie na stronie projektu - http://slidesjs.com/.

Doctrine to obecnie chyba najpopularniejsza biblioteka ORM dla PHP 5.2.x, chętnie wybierana zarówno przez zwykłych programistów, jak i twórców frameworków. Od jakiegoś czasu trwają prace nad zupełnie nową wersją 2.0, która została zaprojektowania od nowa i przyniosła znaczące uporządkowanie architektury. Od kilku miesięcy biorę aktywny udział w jej testowaniu i debugowaniu, dlatego przez ten czas udało mi się wyrobić już pewien sensowny osąd na jej temat, który chciałbym zaprezentować, by już teraz pomóc w odpowiedzi na pytanie "czy warto się przesiadać".