Probably most of us heard about streams in PHP. They are background of all files and network operations in PHP, even if we don't see it. Everytime when you use file_get_contetnts or fopen you are actually using streams. But there are many stream wrappers I haven't used, because they aren't well known.

Felipe Pena, jeden z najaktywniejszych deweloperów PHP wraz z całym szeregiem innych prominentnych uczestników projektu ogłosił RFC – propozycje zmian w cyklu wydawniczym interpretera. Jak dotąd, wszelkie nowe wydania powstawały spontanicznie. Po prostu po zakumulowaniu się jakiejś masy krytycznej nowych rzeczy w repozytorium, ktoś wyskakiwał jak to „Filip z konopi indyjskich” i mówił, że robimy nowego releasa. Skutkowało to tym, że nikt nigdy nie wiedział, kiedy wyjdzie nowa wersja interpretera. Przez to też między innymi tak wolno nowe wersje dostają się na hostingi, czy do stabilnych wydań Debiana. Nie ma też żadnej ścieżki, dzięki której, można by informować o zmianach we wstecznej kompatybilności, przez co bardzo wiele czasu zajmuje usunięcie jakiś śmieci z poprzednich wersji (magic_quotes etc).

RFC proponuje:

• cykliczny okres wydawniczy
• demokratyczny proces podejmowania decyzji, wszelkie zmiany wprowadzane będą poprzez RFC, a decyzja podejmowana poprzez anonimowe głosowanie
• typ zmian, jakie mogą być wprowadzane w poszczególnych rodzajach wydań
• demokratyczny proces wybierania menedżerów wydań dla danego wydania
• efektywniejsze użycie bugs.php.net do śledzenia zmian i błędów
• skrócony czas między wydaniami poprawiającymi błędy
• skrócony czas wprowadzania nowych rzeczy do języka
• brak zrywania kompatybilności wstecznej dla wydań poprawiających błędy
• wydania podglądowe, mające na celu przedstawienie jakiejś funkcjonalności szerszej publice

Więcej szczegółów znajdziecie w RFC, natomiast chciałem jeszcze pokrótce omówić rodzaje wydań.

• Wydania serwisowe – zmiana numerów wersji wg porządku x.y.z -> x.y.z+1 – tylko poprawki błędów, konieczność zachowania kompatybilności wstecznej, nie można usuwać rozszerzeń
• Małe wydania – x.y.z  -> x.y+1.z – poprawki błędów, nowe cechy języka, można usuwać rozszerzenia, konieczność zachowania kompatybilności wstecznej
• Duże wydania – x.y.z -> x+1,y,z – wszystko to samo co w przypadku małych wydań z tą różnicą, że można zerwać kompatybilność wsteczną

Osobiście uważam, że ta propozycja to świetny pomysł. Na pewno przyśpieszy wydawanie nowych wersji, które dzięki przewidywalności daty pojawienia się będą szybciej adoptowane przez hostingi.

Mimo, iż z zawodu jestem programistą PHP, nie śledzę na bieżąco informacji związanych z planowanymi zmianami w tym języku. Najczęściej dowiadywałem się o nich w momencie wydania pierwszej stabilnej wersji. Związane było to głównie z brakiem czasu i ochoty na przegrzebywanie list dyskusyjnych oraz z przeświadczeniem, iż nie ważne co wymyślą w wersji alfa i tak się ona nie ukaże (PHP6 już od dawna wisiało w repozytorium) lub zmiany w stabilnej wersji będą tak dalekie od pierwszej propozycji, że trzeba będzie je poznawać od nowa. Na szczęście znalazł się “szaleniec”, któremu niestraszne są pehapowe listy dyskusyjne i zaczął na swoim blogu publikować najciekawsze informacje ze wspomnianych list. Wojtek Soczyński, bo o nim mowa, popełnił na początku miesiąca wpis zatytułowany Nowości z php.internals – double colon i 5.4 alpha. Pomijając cześć o T_PAAMAYIM_NEKUDOTAYIM, można się z niego dowiedzieć, że chłopaki od PHP szykują nam PHP 5.4, które będzie zawierać wszystko to, co obiecał nam PHP 6, a nawet więcej.

Początkowo chciałem przeczekać cały ten szum, związany z PHP 5.4 – przecież nie wiadomo czy, a jeśli tak, to kiedy będzie wydany. Nie było mi to jednak dane. Od kilku dni jestem bombardowany z każdej strony informacjami o czymś, co będzie zakałą każdego programisty (nie klepacza) – traits. Angielskojęzyczna blogosfera oszalała na punkcie tej funkcjonalności. Średnio co 5 minut pojawia się na Twitterze nowa wiadomość na ten temat.

“If you can't beat them, join them” głosi stara maksyma i postanowiłem postąpić zgodnie z jej zaleceniem. Przejrzałem jeszcze raz na blogu Wojtka wpisy poświęcone wprowadzanym zmianom oraz zajrzałem do SVN-a (http://svn.php.net/viewvc/php/php-src/trunk/NEWS?view=markup). I co się okazało? Że traits wcale nie są najciekawszą zmianą wprowadzaną do PHP. W mojej opinii the best of PHP 5.4 to:

1. Type hint dla typów prostych, czyli:

   class Foo
   {
   	public function bar(int $i)
   	{
   		// some stuff
   	}
   }

   Potrzebna i długo przeze mnie wyczekiwana funkcjonalność pozwalająca na znaczne zredukowanie ilości zbędnego kodu. Obawiam się jedynie o sposób w jaki PHP będzie informował o niepoprawnym typie danych. Oby był to wyjątek.
2. Możliwość korzystania z $this w closure. Każdy kto korzystał z anonimowych funkcji w zasięgu obiektu, doceni tą drobną, acz niezbędną poprawkę.
3. Dostęp do tablicy z poziomu funkcji/metody. Od dawna przeklinałem PHP za brak tej funkcjonalności. W końcu będzie można dostać się do tablicy bezpośrednio z funkcji, np:

   echo foo()[2];

4. Traits. Ta funkcjonalność jest bardzo potrzeba, jednak spowoduje ogromny burdel w projektach i stanie się przykładem antywzorca tak, jak kiedyś stało się to z “obiektem matką”. Kiedyś, aby uzyskać możliwość korzystania z super-niezbędnych-metod, tworzyło się główny obiekt, po którym dziedziczyły wszystkie klasy w projekcie. Dzięki traits będzie można stworzyć “obiekt rój”, czyli dziesiątki (jeśli nie setki) klas, pakowanych do czegoś, co kiedyś było “matką”. Odnalezienie się w gąszczu zależności będzie graniczyło z cudem. Oczywiście poprawnie wykorzystane, będą dawały potężne możliwości, których czasem brakowało. Funkcjonalność ta wprowadza coś, co można porównać do metod rozszerzeń (w sporym uproszczeniu) znanych z C#.

Nie są to jedyne zmiany jakie przyniesie PHP 5.4, jednak na tych najbardziej mi zależy i na nich w pierwszej kolejności się skupię po wydaniu stabilnej wersji 5.4. Nie pozostaje nic innego jak uzbroić się cierpliwość.

Description:

This errors occurs when you keep your dates in unix timestamp format (represented as number of seconds from 1970/01/01). When we want to change a date to the next day, we can simply add as many second as there are in one day, which is 24 * 60 * 60 = 86400 seconds.

However when we try to do this for date: 2010-10-31, it is not working.

$time = strtotime('2010-10-31'); echo date("Y-m-d", $time) . "\n"; // 2010-10-31 $time += 86400; echo date("Y-m-d", $time) . "\n"; // still 2010-10-31

Solution:

Stop adding seconds to dates represented by unix timestamp. Instead, use:

$time = strtotime('2010-10-31'); echo date("Y-m-d", $time) . "\n"; // 2010-10-31 $time = strtotime('+1 day', $time); echo date("Y-m-d", $time) . "\n"; // 2010-11-01

10 listopada proponowałem Wam swoją listą magazynów dostępnych w formacie PDF. Dzisiaj natomiast przychodzi mi wspomnieć o wydaniu Extra magazynu Software Developer’s Journal.

W nowym numerze poświęconym hostingowi (SDJ Extra 1/2010) znajdziecie artykuł mojego autorstwa. Zebrałem w nim wiedzą na temat postawienia lekkiego serwera WWW z PHP na VPS’ie. Dowiecie się jak skompilować nginx (serwer WWW) wraz z php-fpm 5.3.3. Do tego jest wzmianka dlaczego warto korzystać z  APC i memcached.

Taką konfigurację polecam każdemu posiadaczowi VPS‘a. Oczywiście w artykule jest zarysowana wstępna konfiguracja instalowanych usług i na pewno należy ją dostosować pod siebie (chociażby wielkość pamięci RAM przeznaczona dla APC).

Dodatkowo z SDJ Extra 1/2010 dowiecie się:

• Jaki jest polski rynek hostingu?
• Jakimi czynnikami kierujemy się przy wyborze hostingu?
• Serwery VPS
• Wprowadzenie do Amazon Simple Storage Service (S3)
• Wykorzystanie chmury Amazon S3 za pomocą języka PHP
• Hosting w chmurze
• Automatyczne kopie bezpieczeństwa serwisu WWW
• Tworzenie skryptów w technologiach typu Flash i Silverlight

Polecam.

Twitter – darmowy serwis społecznościowy udostępniający usługę mikroblogowania umożliwiającą użytkownikom wysyłanie oraz odczytywanie tak zwanych tweetów. Tweet to krótka, nieprzekraczająca 140 znaków wiadomość tekstowa wyświetlana na stronie użytkownika oraz dostarczana pozostałym użytkownikom, którzy obserwują dany profil.

Informację wstępne

Serwis dostarcza nam bogate API oraz dokumentacje dzięki któremu możemy zbudować nasze aplikacje korzystające z jego możliwości.

W sieci jest dostępna masa przykładów dzięki którym możemy np. dodać tweeta do naszego konta. Przykładowy kod znaleziony w sieci

<?php
$username = 'myUserName';
$password = 'myPassword';
$status = urlencode(stripslashes(urldecode('This is a new Tweet!')));

if ($status) {
$tweetUrl = 'http://www.twitter.com/statuses/update.xml';

$curl = curl_init();
curl_setopt($curl, CURLOPT_URL, "$tweetUrl");
curl_setopt($curl, CURLOPT_CONNECTTIMEOUT, 2);
curl_setopt($curl, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($curl, CURLOPT_POST, 1);
curl_setopt($curl, CURLOPT_POSTFIELDS, "status=$status");
curl_setopt($curl, CURLOPT_USERPWD, "$username:$password");

$result = curl_exec($curl);
$resultArray = curl_getinfo($curl);

if ($resultArray['http_code'] == 200)
echo 'Tweet Posted';
else
echo 'Could not post Tweet to Twitter right now. Try again later.';

curl_close($curl);
}
?>

Niestety, wynikiem powyższego skryptu będzie zawsze komunikat o treści

Could not post Tweet to Twitter right now. Try again later.

Wszelkie możliwości dodawania tweetów w ten sposób zostały zablokowane. Jedyną możliwością jest użycie API.

API

Lista możliwości dostępnych w API jest bardzo duża, lecz zajmiemy się kilkoma podstawowymi funkcjami które dostarcza nam biblioteka ułatwiająca jego wykorzystanie. Mowa o bibliotece o nazwie Twitter for PHP stworzona przez Davida Grudl-a i udostepiona tutaj. Do jej działania wymagane jest PHP5 lub nowsze oraz biblioteka cURL.

Pierwszym krokiem jest założenie konta na Twitter.com a następnie rejestracja swojej aplikacji pod tym adresem. Należy pamiętać aby w formularzu wybrać następujące opcje

Application Type: Client

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

Zwiń
Czytaj na blogu autora...

Testy jednostkowe, jak sama nazwa wskazuje, polegają na testowaniu jednostki - jednego obiektu w ramach jednego zestawu testów. Co jednak w sytuacji, gdy testowany obiekt jest zależny od innego obiektu? Przy bezpośrednim wykorzystaniu tego dodatkowego obiektu w testach jednostkowych jest łamana podstawowa ich zasada. Przy wykorzystaniu rzeczywistego obiektu pomocniczego, robimy ślepe założenie, że działa on prawidłowo i nie zakłóci on wyników testów. Innymi słowy testy mogą się nie powieść, ale nie oznacza to jednoznacznie, że to w testowanej klasie jest błąd. Sytuacja może się również paradoksalnie odwrócić, testy zostaną przeprowadzone prawidłowo, mimo iż testowana klasa zawiera błędy, które powinny zostać wykryte.

Jedno z rozwiązań tego problemu przedstawiłem w poprzednim wpisie na temat wzorca Service Stub. Teraz postaram się pokazać inne podejście, a mianowicie wykorzystanie obiektów Mock.

Zazwyczaj test wygląda tak, że wywołujemy operacje na obiekcie testowanym, a następnie przeprowadzamy asercje na stanie tego obiektu - nazywa się to weryfikacją stanu. Inne podejście do testowania mówi o testowaniu zachowania danego obiektu, a nie jego stanu - interesuje nas nie to, czy po wywołaniu metody prawidłowo zmienił się stan obiektu, ale to czy obiekt ten zachował się prawidłowo.

Prosty przykład oprę na chyba najprostszej z możliwych implementacji wzorca Composite:

[PHP]
class Composite 
{
  private $parent;
  private $children = array();
 
  private function setParent(Composite $parent) 
  {
    $this->parent = $parent;
  }
 
  public function addChild(Composite $child) 
  {
    if ($child->getParent()) {
      $child->getParent()->remove($child);
    }
 
    $child->setParent($this);
    $this->children[] = $child;
  }
 
  public function remove(Composite $child) 
  {
    $index = $this->findChildIndex($child);
 
    if ($index !== null) 
    {
      unset($this->children[$index]);
      return true;
    }
 
    return false;
  }
 
  public function getChildren() 
  {
    return $this->children;
  }
}

Chcemy przetestować dodawanie potomków, tak więc na początku sprawdzamy ile potomków ma testowany obiekt, dodajemy obiekt i ponownie sprawdzamy liczbę potomków:

[PHP]
class CompositeTest extends PHPUnit_Framework_TestCase 
{
  private $composite;
 
  public function setUp() 
  {
    $this->composite = new Composite();
  }
 
  public function testAddingChildren() 
  {
    $this->assertEquals(0, count($this->composite->getChildren()));
 
    $child = new Composite();
    $this->composite->addChild($child);
 
    $this->assertEquals(1, count($this->composite->getChildren()));
  }
}

W tym teście interesuje nas efekt, czyli to czy po dodaniu dziecka faktycznie stan testowanego obiektu się zmienił.

Przy wykorzystaniu obiektu Mock weryfikujemy to, w jaki sposób zachował się testowany obiekt. Sprawdzamy, czy wywołał on określoną liczbę razy odpowiednie metody obiektu Mock. W naszym przypadku sprawdzamy, czy metody getParent oraz setParent zostały wywołane dokładnie po jednym razie na rzecz obiektu dziecka.

[PHP]
//ciach...
  public funciton testAddingChildrenByMockObject()
  {
    $mock = $this->getMock('Composite', array('getParent', 'setParent'));
    $mock->expects($this->once())//spodziewamy się wywołania dokładnie raz metody getParent, zwróci ona false
         ->method('getParent')
         ->will($this->returnValue(null));
    $mock->excepts($this->once())//spodziewamy się wywołania dokładnie raz metody setParent
         ->method('setParent');
 
    $this->composite->addChildren($mock);
  }

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

Zwiń
Czytaj na blogu autora...