Kilka dni temu na zagranicznym forum DevNetwork poświęconym programowaniu w PHP pojawił się temat zatytułowany phpDoc jako duplikacja kodu z pytaniem "czy także uważacie, że komentarze phpDoc to bezsens, a jeśli nie, do czego się właściwie przydają?" Może to niektórych zdziwić, ale powstała mała burza, i to nie przeciwko autorowi, ale właśnie w jego poparciu. Dlatego postanowiłem przyjrzeć się nieco bliżej kwestii dokumentacji tym bardziej, że jakiś czas temu sam zostałem - co tu dużo mówić - zjechany za nieużywanie phpDoc-ów.

Po zapoznaniu się z teorią chmur, nadeszła pora na zajęcia praktyczne. Na pierwszy ogień idą mechanizmy przechowywania danych, a dokładniej bloby.

Co to jest blob?

Blob (binary large object), jest dowolnym zestawem bitów (danych binarnych). W postaci bloba można przechowywać w Windows Azure dowolne pliki, takie jak zdjęcia, muzyka, wideo, archiwa zip, dokumenty tekstowe, itp.

Odrobina teorii

Mimo, iż napisałem, że przejdziemy do zajęć praktycznych, będę musiał jeszcze przez chwilę ponudzić.

Dane przechowywane w postaci bloba, umieszczane są w kontenerach. Kontener można porównać do katalogu na dysku, w którym znajdują się pliki (bloby). W przeciwieństwie do katalogów, kontenerów nie można zagnieżdżać. Rozwiązaniem tego problemu jest umożliwienie stosowania ukośnika (/) w nazwie bloba, co symuluje drzewo katalogów.

Do każdego kontenera oraz bloba można dołączyć metadane o maksymalnym rozmiarze 8kB w postaci klucz,wartość.

W przypadku Windows Azure bloby dzielą się na dwa rodzaje: block blobs oraz page blobs. Pierwszy rodzaj blobów podczas uploadowania do chmury dzielony jest na mniejsze elementy (bloki). Dzięki temu można równolegle uploadować wiele bloków na raz, co znacznie przyspieszy cały proces. Drugi rodzaj blobów umożliwia skorzystanie z czegoś, co nazywa się XDrive. Jest to wirtualny dysk, który umożliwia pracę z blobem tak, jakbyśmy pracowali z najzwyklejszym systemem plików.

Ostatnim tematem o jakim należy wiedzieć, jest bezpieczeństwo danych przechowywanych jako bloby. Jak już wspomniałem, bloby przechowywane są w kontenerach. Mogą one być prywatne lub publiczne. Bloby dziedziczą uprawnienia po kontenerach, w których się znajdują. Na szczęście mamy możliwość skorzystania z Shared Access Signatures. Dzięki SAS mamy wpływ na znacznie więcej parametrów, niż publiczny-prywatny. Przy jego pomocy możną określić, czy dostęp do danego bloba (lub kontenera) jest na zasadzie tylko odczyt, czy np odczyt-zapis.

Czas na praktykę

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

Zwiń
Czytaj na blogu autora...

cURL biblioteka umożliwiająca wysyłanie zapytań http w tym pobieranie z serwerów stron i plików, a także wysyłanie treści formularzy oraz porozumiewanie się za pomocą najbardziej popularnych protokołów sieciowych, takich jak HTTP, FTP, TFTP, TELNET, DICT, FILE i LDAP.

W czasie tworzenia niektórych aplikacji w języku PHP występuje potrzeba szybkiego wysłania różnego rodzaju żądań przy użyciu protokołu http. W poniższym artykule postaram się przedstawić podstawy obsługi funkcji curl_multi_* dzięki którym jesteśmy w stanie zrealizować założony cel.

<?php

$pages = array('http://www.onet.pl','http://www.wp.pl', 'http://www.google.pl');
$ch = array();
$results = array();

$mh = curl_multi_init();

for($i=0;$i<count($pages);$i++) {

$ch[$i] = curl_init();
curl_setopt($ch[$i], CURLOPT_URL, $pages[$i]);
curl_setopt($ch[$i], CURLOPT_HEADER, 0);

curl_multi_add_handle($mh,$ch[$i]);

}

do {
 $result = curl_multi_exec($mh, $active);
 } while ($result == CURLM_CALL_MULTI_PERFORM);

 do {
 if (curl_multi_select($mh) != -1) {
 do {
 $result = curl_multi_exec($mh, $active);
 } while ($result == CURLM_CALL_MULTI_PERFORM);
 }
 } while ($active && $result == CURLM_OK);

for($i=0;$i<count($pages);$i++) {

$results[$i]['info'] = curl_getinfo($ch[$i]);
$results[$i]['content'] = curl_multi_getcontent($ch[$i]);

curl_multi_remove_handle($mh, $ch[$i]);

}

curl_multi_close($mh);

?>

Na samym początku skryptu deklarujemy zmienne których będziemy używali w trakcie jego działania.

$pages = array('http://www.onet.pl','http://www.wp.pl', 'http://www.google.pl');
$ch = array();
$results = array();

Inicjacja multi cURL i przypisanie do zmiennej o nazwie mh.

$mh = curl_multi_init();

Następnie w pętli inicjujemy poszczególne uchwyty przy pomocy funkcji curl_init() i dodajemy do głównego żądania za pomocą funkcji curl_multi_add_handle. Odnośnie parametrów dodanych za pomocą funkcji curl_setopt zapraszam do zapoznania się z dokumentacją funkcji cURL.

for($i=0;$i<count($pages);$i++) {

$ch[$i] = curl_init();
curl_setopt($ch[$i], CURLOPT_URL, $pages[$i]);
curl_setopt($ch[$i], CURLOPT_HEADER, 0);

curl_multi_add_handle($mh,$ch[$i]);

}

Dochodzimy do sedna sprawy która może stać się problematyczna. W jaki sposób wykonywać poszczególne żądania tak aby nie blokowały się wzajemnie, służy nam do tego dość zawiły kod.

do {
 $result = curl_multi_exec($mh, $active);
 } while ($result == CURLM_CALL_MULTI_PERFORM);

 do {
 if (curl_multi_select($mh) != -1) {
 do {
 $result = curl_multi_exec($mh, $active);
 } while ($result == CURLM_CALL_MULTI_PERFORM);
 }
 } while ($active && $result == CURLM_OK);

Po wykonaniu powyższego fragmentu przystępujemy do pobrania informacji o wykonanych żądaniach używając do tego funkcji curl_getinfo i curl_multi_getcontent oraz usunięciu uchwytów curl_multi_remove_handle.

for($i=0;$i<count($pages);$i++) {

$results[$i]['info'] = curl_getinfo($ch[$i]);
$results[$i]['content'] = curl_multi_getcontent($ch[$i]);

curl_multi_remove_handle($mh, $ch[$i]);

}

Na koniec zamykamy główne żadanie

curl_multi_close($mh);

W tym artykule to już wszystko. Zapraszam do komentowania i zadawania pytań.

Test-Driven JavaScript Development Okładka

Ten wpis jest moją pierwszą próbą napisania recenzji książki. Zacznijmy więc od mojej najnowszej pozycji: Test-Driven JavaScript Development napisanej przez Christiana Johansena. Jak napisano na tylnej okładce, Test-Driven JavaScript Development jest kompletnym zbiorem najlepszych praktyk, poradnikiem dla testów JavaScript w metodyce agile oraz zapewniania jakości z użyciem metodologii programowania sterowanego testami (TDD).

Na początku pragnę podziękować autorowi – Christianowi, który dał mi tę książkę na konferencji Front-Trends 2010. Książka jest bardzo świeża (pierwszy druk, wrzesień 2010), tym bardziej jestem podekscytowany jej posiadaniem. Dzięki Christian

Kim jest autor?

W swojej karierze zawodowej Christian Johansen specjalizował się na internecie oraz programowaniu front-end’u przy użyciu technologii takich jak JavaScript, CSS i HTML przy użyciu rozwiązań agile. Często wnosi wkład w open source, bloguje o JavaScript, Ruby, i tworzeniu stron internetowych na cjohansen.no. Christian pracuje w Shortcut, norweskiej firmie programistycznej, koncentrującej się na otwartych technologiach, aplikacjach internetowych i aplikacjach mobilnych.

Pozostawiając kodowanie w „stylu kowbojskim” starał się poprawiać jakość i zaufanie do kodu. Spędził wiele czasu badając testy jednostkowe i TDD w JavaScript.

Mieszka w Oslo, w Norwegii.

O czym jest ta książka?

Automatyczne testowanie dostarcza rozwiązania do manualnego procesu testowania. Łatwiej, szybciej jest zrobić test automatycznie niż ręcznie. Programowanie sterowane testami idzie o krok dalej. Przesuwa testy jednostkowych do pierwszego wiersza, czyniąc je głównym punktem. W TDD testy są pisane przed pisaniem produkcyjnego kodu.

Książka zorganizowana jest w 4 częściach. Każda część może być czytana w innym niż sugerowanym porządku. Generalnie książka jest o programowaniu w języku JavaScript dla prawdziwego świata za pomocą podejścia wykorzystującego programowanie sterowane testami. To nie jest tylko styl programowanie, to jest to zaufanie do kodu z powodu pokrycia testami, możliwość refaktoringu kodu bez lęku. Chodzi o pisanie modułowego kodu, który może być łatwo przetestowany.

1. Programowanie sterowane testami
2. JavaScript dla programistów
3. Prawdziwy świat programowania sterowanego testami w JavaScript
4. Wzorce testów

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

Zwiń
Czytaj na blogu autora...

Ostatnio gdzie nie zajrzę, pojawia się tajemnicze hasło testy jednostkowe, unit tests lub co gorsza Test-driven development. Od kilku dni bawię się testami automatycznymi i śmiało mogę powiedzieć, że mają sens, a co więcej, wprowadzają dużo więcej zabawy do programowania.

Na czym to ustrojstwo polega? W chwili pisania kodu, w osobnym pliku równocześnie piszemy do niego testy. Pisząc w TDD zaleca się najpierw napisanie testu, a dopiero potem kod, który spełnia dany test! Fajne, co? Testy pilnują żeby podczas rozbudowy/refaktoryzacji kodu całość działała.

Im trudniej spełnić test, tym lepiej. Kluczowe jest przewidzenie reakcji kodu na wartości graniczne oraz momenty, kiedy coś się popsuje. Jeżeli kiedykolwiek musimy użyć var_dump(), to od razu powinna nam się zapalić lampka w głowie, że można napisać test.

Jak w ogóle się za to zabrać? Potrzebujemy aplikacji testującej o nazwie PHPUnit. Na stronie jest również fajna dokumentacja (co prawda po angielsku, ale napisana bardzo prostym językiem). W Ubuntu można łatwo sobie doinstalować program poprzez Synaptic (trochę starszą wersję, ale to nic).

Druga sprawa, której potrzebujemy to kod do testowania. Na szybko napisałem sobie prostą klasę szyfrującą ciasteczka za pomocą wybranego algorytmu, trybu i hasła. Nie wiem czy użytkownikom spodobałoby się trzymanie u siebie czegoś, do czego nie mają dostępu, ale cóż… potrzebowałem materiału do testów. Jest tego kilkadziesiąt linijek, dlatego wkleiłem do Pastebin.

Jak kogoś interesuje, to używa się tego dosyć prosto: tworzymy obiekt, wybieramy jeden z algorytmów modułu mcrypt (który wcześniej musimy mieć zainstalowany!), tryb i hasło, a następnie za pomocą metody setEncryptedCookie() ustawiamy cookie. Mając ustawiony obiekt, getEncryptedCookie() wyciągnie nam cookie i rozszyfruje treść.

$cookieEncrypter = new SpiechuCookieEncrypter();
$cookieEncrypter->setAlgorithm('twofish')
        ->setMode('cbc')
        ->setPassword('jakies haslo')
        ->setEncryptedCookie('testowe_ciacho', 'testowa wartosc ciacha');
 
echo $cookieEncrypter->getEncryptedCookie('testowe_ciacho');

Jeżeli do kodowania używacie NetBeansa, to pod prawym przyciskiem nad nazwą pliku jest wygodna opcja, która stworzy nam „szkieletor” testów (Tools->Create PHPUnit tests).

Zasada jest taka, że klasa testująca musi rozszerzać klasę PHPUnit_Framework_TestCase. Ponadto przyjęło się, że nazwa kończy się słowem *Test, za to wszystkie metody testujące muszą zaczynać się od test*.

Testy operują na asercjach, czyli specjalnych metodach, których warunek musi zostać spełniony aby test powiódł się. I tak, dla przykładu assertEqual($wartosc1,$warosc2) zgłosi nam błąd, jeżeli obydwie wartości nie są takie same. Jest tego w hu hu, dlatego zainteresowanych skieruję do źródła.

Oprócz metod testCośTam mamy jeszcze dwie metody specjalnego przeznaczenia: setUp() i tearDown(). Pierwsza jest odpalana przed każdym testem, druga po teście. Polegają na przygotowaniu środowiska do testów i „posprzątanie” po teście. W moim przypadku setUp tworzy obiekt testowany i umieszcza w polu obiektu testującego, a tearDown jest puste, bo nie miałem np. otwartych plików, połączeń do bazy czy innych rzeczy, które trzeba by zamknąć.

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

Zwiń
Czytaj na blogu autora...

Na początku listopada 2010 odbyła się konferencja ZendCon 2010. Spośród wszystkich informacji jakie na jej temat pojawiają się w sieci, brakuje jednej – wydano kolejny milestone drugiej wersji Zend Frameworka. W tym wydaniu zabrano się za autoloadera, ładowanie pluginów oraz wyjątki.

Autoloader

W dziedzinie automatycznego ładowania klas możemy spodziewać się następujących zmian:

• dostarczenie mapy klas dla całego frameworka oraz poszczególnych komponentów
• nowy loader bazujący na mapie klas
• nowe narzędzia do generowania map

Ładowanie pluginów (Plugin Loading)

Pluginy w ZF są przydatnym mechanizmem, jednak ich stosowanie wiązało się z kilkoma problemami. Największym z nich jest wydajność, a raczej jej brak. Dzięki nowemu podejściu bazującemu na mapowaniu klas, udało się zmniejszyć ilość wywołań potrzebnych do wykonania kodu w pluginie z 19 do 7.

Wyjątki

Wyjątki zostały tak przepisane, by każdy z komponentów posiadał jeden marker, który będzie bazowym interfejsem dla poszczególnych wyjątków w danym komponencie. Ponadto wyjątki będą rozszerzać klasy wyjątków dostarczane w ramach SPL.

Co dalej?

Następne w kolejności jest MVC oraz wszystkie powiązane z nim komponenty, czyli Zend\View, Zend\Layout, Zend\Navigator oraz Zend\Form. Podobno prace już trwają. Kiedy zostaną przedstawione szerszej publiczności? Prawdopodobnie za kilka miesięcy.

Dokładne informacje na temat drugiego milestone’a oraz linki do pobrania znajdziecie pod adresem http://framework.zend.com/announcements/2010-11-03-zf2dev2.

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

Zwiń
Czytaj na blogu autora...

Zadanie jak z podstawówki jednak niektórym stwarza problemy.

<?php
$l1 = 18;
$l2 = 20;

$result = ($l1/$l2) * 100;

echo $result.'%';
?>

Wynikiem działania skryptu będzie

90%