Zend Developer Cloud w przeciwieństwie do PHP Fog oferuje możliwość logowania się do chmury przy pomocy protokołu SFTP. Stwarza to dodatkowe możliwości deploy’u aplikacji do chmury. Jeśli korzystacie z PHPStorm i z jakiegoś powodu nie chcecie/nie możecie używać Gita do przesyłania aplikacji do chmury, deploy wykonacie przy pomocy wbudowanego narzędzia Deployment.
Zanim zaczniemy, musimy przygotować nowy projekt. W tym celu w serwisie my.phpcloud.com należy utworzyć nową aplikację (nazwa na załączonym obrazku jest przykładowa, możecie użyć własnej).
Następnie musimy sklonować repozytorium projektu (jest to jedyny raz, gdy użyjemy gita). W celu sklonowania repozytorium najlepiej skorzystać z wbudowanych w PHPStorm narzędzi.
Jedyne co nam pozostało do zrobienia, to skonfigurowanie narzędzia Deployment. Aby to zrobić, z menu Tools wybieramy opcję Deployment. W oknie, które się pojawi, uzupełniamy nazwę hosta, zmieniamy port na 22, podajemy ścieżkę do klucza prywatnego będącego parą do klucza publicznego przesłanego do chmury, a na końcu wybieramy katalog root.
W zakładce Mappings musimy wskazać katalogi, które mają się synchronizować.
Ostatnią czynnością jaką musimy wykonać jest ustawienie nowoutworzonej konfiguracji jako domyślnej oraz włącznie opcji automatycznego uploadu. Wystarczy teraz, że dodamy, usuniemy lub zmodyfikujemy plik, a zostanie on automatycznie zsynchronizowany z projektem w chmurze. Jeśli okaże się, że pliki nie synchronizują się automatycznie, niezbędne będzie jednorazowe ręczne wysłanie plików.
W dniu wczorajszym PHP Fog poinformował o zniesieniu sześciomiesięcznego limitu na bezpłatne aplikacje, po którym należało usunąć aplikację lub zmigrować do aplikacji płatnej. Blogosfera się ucieszyła, pojawiły się pozytywne reakcje na ten ruch i wydawać by się mogło, że szum wokół PHP Fog ucichnie tak szybko jak się podniósł, gdy nagle pojawiła się kolejna informacja o zmianach i to nie małych.
Od dzisiaj aplikacje tworzone w chmurze PHP Fog zyskały mechanizm dodatków (Add-Ons). Na starcie są to tylko (a może aż) dwa dodatki MongoDB oraz NewRelic. Pierwszy z nich to znana i lubiana baza NoSQL, drugi – monitoring aplikacji. Oba dodatki obsługiwane są przez zewnętrzne firmy i to w nich rezydują panele administracyjne oraz w nich uiszcza się dodatkowe opłaty.
W przypadku MongoDB obsługą bazy zajmuje się serwis MongoLab.com, do którego zostaniemy przekierowani po dodaniu rozszerzenia. Niestety dokumentacja PHP Fog jest wyjątkowo oszczędna w informacje i o cenach dowiadujemy się dopiero po aktywowaniu rozszerzenia. Na szczęście baza do 240 MB jest bezpłatna. Problemem jest jak się okazuje usunięcie bazy, które odnotowywane jest tylko w MongoLab.com. PHP Fog nie jest świadome tego faktu i wyświetla link do zarządzania nieistniejącą bazą, po kliknięciu w który otrzymujemy komunikat o braku bazy. Warto wiedzieć, iż PHP Fog oraz MongoLab to niezależne usługi, które oddzielnie zarządzają swoimi chmurami. Według zapewnień z dokumentacji zarówno baza jak i aplikacja znajdują się w tym samym datacenter, co ma zmniejszyć opóźnienia.
NewRalic z kolei obsługiwany jest przez stronę NewRelic.com i jest dostępny tylko dla dedykowanych chmur. Niestety dokumentacja nie zawiera żadnych dodatkowych informacji na ten temat.
Mimo iż wyścig do chmury dopiero się rozpoczyna, PHP Fog mocno ruszył do przodu i konkurencyjne platformy, które powstaną w przyszłości, będą miały nie lada problem, by nadrobić zaległości, zwłaszcza że kolejni partnerzy już czekają ze swoimi produktami na wdrożenie.
Jedna z pierwszych, jeśli nie pierwsza, chmura dedykowana dla PHP – PHP Fog, zaktualizowała swój cennik i usunęła limit sześciu miesięcy, po których darmowa aplikacja działająca w ramach współdzielonej chmury musiała zostać zamieniona w aplikację płatną lub usunięta. Co więcej, otrzymujemy możliwość utworzenia aż trzech darmowych aplikacji w ramach jednej chmury. To nie wszystkie nowości. PHP Fog wzbogacił się o nowe aplikacje oraz frameworki i w chwili obecnej obsługuje:
Jak widać lista jest całkiem imponująca i wiele jej nie brakuje.
Zakładając darmową aplikacją musimy jednak pamiętać o ograniczeniach jakie są na nas nakładane – współdzielona pamięć i procesor, 100MB pojemności dyskowej oraz 15 GB limitu transferu danych. Ponadto nie mamy możliwości podpięcia własnej domeny. Niestety nie udało mi się znaleźć dokładnych informacji na temat pamięci, procesora oraz bazy danych.
Do czego taka darmowa chmura może nam posłużyć? Przede wszystkim jako poligon doświadczalny dla naszych aplikacji oraz jako miejsce, z którego możemy pokazywać klientom kolejne etapy powstawania ich aplikacji. Oczywiście nic nie stoi na przeszkodzie aby uruchomić we współdzielonej chmurze nasz własny projekt i w razie konieczności zmigrować go do dedykowanej chmury.
Witajcie, dzisiaj zaprezentuję wam szalenie przydatny trik, który znajduje zastosowanie zawsze wtedy, kiedy skrypt ma do wykonania jakieś czasochłonne zajęcie a nie chcielibyśmy zbytnio wystawiać na próbę cierpliwość naszych użytkowników. Zatem do dzieła!
Wyobraźmy sobie sytuację, w której użytkownik wchodzi na naszą stronę aby pobrać jakieś dane. Skrypt szybciutko łączy się z bazą i przekazuje mu je najszybciej jak to możliwe. Założenia naszego systemu wymagają jednak, aby każde działanie użytkownika było logowane do bazy. Normalnie połączenie użytkownik->skrypt pozostałoby otwarte, co skutkowałoby tym, że musiałby on bezsensownie czekać na zakończenie działania programu. To jest tylko przykładowa sytuacja, ale są i takie, w których skrypt po wysłaniu odpowiedzi musi się jeszcze wykonywać nawet przez dobre parę sekund. Rozwiązanie, które wam zaprezentuje rozwiąże ten problem.
Skorzystamy tutaj z możliwości PHP do buforowania danych wyjścia. Kluczem do zaoszczędzenia cennego czasu jest tutaj wysyłanie odpowiednich nagłówków, które powiedzą przeglądarce, czy i w którym momencie ma zamknąć połączenie/zakończyć ładowanie strony. Na początek kod:
Kanał ATOM
<?php
// otwieramy bufor
ob_start();
// tutaj przetwarzamy i wyświetlamy wszystkie dane
// pobieramy wielkość bufora
$wielkoscOdpowiedzi = ob_get_length();
// wysyłamy nagłówki mówiące przeglądarce o zamknięciu połączenia
header("Content-Length: $wielkoscOdpowiedzi");
header('Connection: close');
header('Content-Encoding: none');
// wysyłamy dane z bufora
ob_end_flush();
ob_flush();
flush();
// zamykamy obecną sesję
if (session_id()) session_write_close();
//proces który leci sobie dalej w tle
sleep(10);
?>
Teraz małe objaśnienie. Na początku otwieramy bufor, wszystkie dane jakie potem wyślemy w nim lądują, następnym krokiem jest pobranie rozmiaru bufora, aby potem przekazać przeglądarce po ilu bajtach może skończyć ładowanie strony. Potem wysyłamy wszystkie nagłówki, w tym momencie należy pamiętać, że w tym przykładzie kompresja gzip musi być wyłączona. Jest to spowodowane faktem, że normalnie kompresja następuje po wykonaniu skryptu, co skutkuje różnicą pomiędzy wielkością przesyłanych danych a zadeklarowanym rozmiarem w nagłówku Content-Length. Kolejnym krokiem jest wysłanie całej zawartości bufora oraz zamknięcie sesji dla danego pliku tak aby nie nastąpiła interferencja, kiedy użytkownik będzie przeglądał dalej stronę podczas gdy skrypt nie zakończy jeszcze swojego działania. I teraz najlepsze, cała praca skryptu wykonywana po tych działaniach będzie miała miejsce tak jakby „w tle” i nie będzie już odczuwalna dla użytkownika. Warto dodać ignore_user_abort(true); na początku skryptu, co uczyni go niewrażliwym na zatrzymanie poprzez kliknięcie przycisku STOP w przeglądarce.
Tutaj sytuacja wygląda prościej i nie wymaga „przemeblowywania” kodu. Jeśli skrypt nic nie wyświetla podczas wykonywania a chcemy uzyskać taki sam efekt jak najszybszego uruchomienia programu i zamknięcia połączenia wystarczy na początku skryptu dodać:
header("HTTP/1.0 204 No Content");
Spowoduje to natychmiastowe zakończenie połączenia przez przeglądarkę/cURL/fsockopen przy dalszym wykonywaniu skryptu. Bajecznie prosta metoda, której warto używać zawsze wtedy, kiedy nie przekazujemy nic do przeglądarki.
To będzie na tyle moich dzisiejszych wypocin 
Mam nadzieje, że te dwa sposoby pozwolą wam na tworzenie jeszcze bardziej rozbudowanych a mimo to jeszcze szybszych serwisów.
Pozdro!
Tagged: bufor, curl, fsockopen, PHP
"In object-oriented languages the term "interface" is often used to define an abstract type that contains no data, but exposes behaviors defined as methods."Istotnym fragmentem tego zdania jest: '[...] exposes behaviors defined as methods.', czyli interfejs definiuje pewne zachowania w postaci metod, których ciało należy zaimplementować w każdej klasie, która implementuje dany interfejs.Dzięki temu możemy określić jakie zachowanie mają posiadać klasy.Czytaj więcej »
