Komponent formularzy frameworka symfony jest naprawdę bardzo potężnym narzędziem, pozwalającym na tworzenie zaawansowanych rozwiązań przetwarzających dane pochodzące od użytkownika na odpowiednią formę. O ile przetwarzanie formularza zazwyczaj sprowadza się do operacji na przesłanych do niego danych, o tyle czasem potrzebujemy innych, zawartych poza jego polami. W dzisiejszym wpisie chciałbym pokazać, w jaki sposób przekazać te [...]

W dziesiątej, jubileuszowej można by rzec, edycji rozdawania książek, mam dla was JavaScript: The Good Parts.

Książka napisana jest w języku angielskim i zawiera autograf autora – Douglasa Crockforda.

Książkę otrzyma osoba, która odpowie na pytanie: “Dlaczego JavaScript?”. Czas nadsyłania odpowiedzi do końca weekendu, czyli do końca dnia 14.08.2011.

Powodzenia!

pre { border: #aaa solid 1px; padding: 10px; margin: 5px 5px 15px 5px; font-family: "Courier New",Courier,monospace; background-color: #f9f9f9; } pre span.key_word { color: #006699; font-weight: bold; } pre span.comment { color: #008200 } pre span.variable{ color: #AA7700} p { margin: 0px; } O tym czym różnią się operatory widoczności można przeczytać tutaj.Ostatnio zauważyłem dziwną tendencję do używania jedynie dwóch z nich, a mianowicie protected i public. Publiczne są metody (ewentualnie dane), które mają być dostępne na zewnątrz, a wszystko inne jest chronione. W myśl zasady: może kiedyś będę tą klasę rozszerzał. Osobiście nie zgadzam się z takim podejściem. Projektując klasę wiemy, co chcemy aby robiła, a takie wybieganie w przyszłość 'bo może coś się przyda' powoduje niepotrzebny śmietnik.Moim zdaniem głównymi operatorami, na których powinien się opierać programista projektując klasę, to private i public, a dopiero w dalszej kolejności protected.Decyzja o tym, którego operatora należy użyć będzie łatwiejsza o ile będzie się pamiętało o kilku rzeczach:

• Enkapsulacja, czyli atrybuty klas powinny być prywatne. Dlaczego? Krótko i rzeczowo jest to wyjaśnione tutaj.
• Gdy już mamy atrybuty klasy, trzeba zastanowić się do czego ta klasa będzie wykorzystywana i na tej podstawie należy zdefiniować metody publiczne, czyli te, które będą wykorzystywane przez inne klasy.
• Jeżeli nie planujesz w obecnej chwili, aby klasa była rozszerzana, to wszystkie metody, które nie są wykorzystywane poza klasą powinny być prywatne. Jeżeli zakładasz, że "może w przyszłości", to również zostaw je jako prywatne. Kod nie jest stałym bytem, może ewoluować, a więc jeżeli zajdzie potrzeba, to zawsze możesz go rozszerzyć lub zmienić.
• Jeżeli klasa będzie rozszerzana, to metodami chronionymi powinny być jedynie te, które są potrzebne w klasie pochodnej, a nie wszystkie niepubliczne.
• Jeżeli klasa pochodna powinna mieć dostęp do atrybutów klasy, do których nie ma akcesorów, to nie oznacza, że należy zmienić widoczność atrybutów na protected. To oznacza, że można dodać chronione settery i/lub gettery.
• Zastanów się trzy razy zanim podejmiesz decyzję o zmianie operatora private na protected w metodach, dziesięć razy jeżeli chcesz to zrobić z atrybutem.
• Gruntownie przemyśl decyzję o wyciągnieciu metody na zewnątrz, czyli zmianie operatora na public. Rób to tylko wtedy, gdy metoda jest rzeczywiście potrzebna poza klasą.
• Rzadko istnieje rzeczywista potrzeba zmiany operatora widoczności atrybutu z private na mniej restrykcyjny - protected. Jeszcze rzadziej zachodzi potrzeba upublicznienia atrybutu.

Mam nadzieje, że tych kilka wskazówek się przyda:)

W ramach przedmiotu „Metody Sztucznej Inteligencji” na studiach musiałem zaprogramować prosty automat komórkowy wzorowany na obliczeniach Wolframa. Automat taki napisałem w JavaScript + HTML/CSS i udostępniam innym, być może komuś się przyda (na pewno kolejnym studentom mojego kierunku ;)). Nie będę rozpisywał się o automatach komórkowych czy metodach sztucznej inteligencji – po prostu ten temat [...]

PHPFog jest chmurą dedykowaną dla PHP, oferującą możliwość bezproblemowego wdrażania i utrzymywania aplikacji. Do dyspozycji otrzymujemy predefiniowane konfiguracje dla frameworków takich jak Zend Framework, Kohana, CakePHP oraz aplikacji typu WordPress, Drupal czy Joomla. Jedyną wadą PHPFog jest jego cena, która zaczyna się od 29 dolarów miesięcznie. W cenę wliczony jest hosting aplikacji, bazy danych 100GB na transfer danych, repozytorium Git, współdzielony SSL oraz domeny typu wildcard.

Firma stojąca za PHPFog – AppFog – otrzymała dofinansowanie w wysokości 8 milionów dolarów na dalszy rozwój chmury. Pieniądze zostaną przeznaczone na poszerzenie listy obsługiwanych frameworków oraz aplikacji. Co więcej, AppFog planuje stworzenie chmury obsługującej takie technologie jak Node.js, Ruby, Python, Java oraz .NET.

Pozostaje mieć nadzieję, iż dofinansowanie pozwoli obniżyć koszt utrzymywania aplikacji w chmurze. Obecnie jedynie cena powstrzymuje indywidualnych użytkowników przed korzystaniem z chmury na większą skalę.

źródło: gigaom.com

Nginx jest lekkim serwerem przeznaczonym do serwowania statycznych plików. Nic nie stoi na przeszkodzie, aby uruchomić na nim PHP. Co więcej, w przypadku Windowsa możemy niewielkim nakładem pracy, przygotować przenośny serwer działający nawet z pendrive’a. I co najważniejsze – nie musimy nic instalować.

Zaczniemy od pobrania Nginx, ze strony http://nginx.org/en/download.html (ściągamy najnowszą stabilną wersję dla Windowsa). Następnie pobieramy PHP w postaci archiwum ZIP – http://windows.php.net/download/. Serwer oraz PHP rozpakowujemy do katalogów nginx i php, które wcześniej utworzyliśmy w dowolnym miejscu (nawet na pendrivie).

Następnie w pliku nginx.conf, znajdującym się w katalogu nginx/conf, wyszukujemy zakomentowany blok rozpoczynający się od location ~ \.php$ { i go usuwany. W jego miejsce powinien trafić następujący kod:

location ~ \.php$ {
	include fastcgi.conf;
	fastcgi_pass  127.0.0.1:9000;
}

I już. Serwer mamy skonfigurowany i gotowy do działania. Jedyne co musimy teraz zrobić, to uruchomić PHP by nasłuchiwało połączeń przez CGI (polecenie wydajemy w katalogu php)

php-cgi -b 127.0.0.1:9000

oraz uruchomić serwer (polecenie wykonujemy w katalogu nginx)

nginx

Teraz możemy utworzyć w katalogu nginx/html plik, np index.php, dodać do niego funkcję phpinfo() i uruchomić wpisując w przeglądarce adres http://localhost/index.php.

W dzisiejszym odcinku weźmie udział „najwspanialszy z kiedykolwiek stworzonych silnik do walidacji danych w PHP” — Validation. Projekt rozwija groźnie brzmiąca grupa programistów o nazwie Respect z Brazylii. Mam nadzieję, że po tym wpisie nie wyląduję w lesie wyciągnięty z bagażnika jakiegoś starego Mercedesa…

Projekt spełnia normy, które są oczywiste przy czytaniu kodu takich gigantów jak Zend Framework 2 czy Symfony, a więc używanie namespaces, drzewiasta struktura klas i katalogów, kompatybilność ze standardowym autoloaderem klas SplClassLoader, własne rozszerzenia wyjątków. Jedyny zgrzyt to poziom dokumentacji. Automat raczej nie da rady w pełni wygenerować typów parametrów metod i zwracanych wartości. W nagrodę za to dostępnych jest dziesiątki testów jednostkowych. Co jak co, ale walidator sprawdzający czyjeś dane sam powinien być gruntownie sprawdzony

Powszechnie wiadomo, że w PHP nie można użyć konstrukcji typu

new Obiekt()->metoda();

Zamiast tego można stosować metody statyczne, które w rezultacie zwrócą nam obiekt lub też można zastosować tak lubianego przez was Harrego Pottera. Twórcy biblioteki czarują często i gęsto.

Autorzy Validation proponują używanie w następujący sposób:

// deklarujemy uzywany namespace i robimy alias do klasy Validator
use Respect\Validation\Validator as v;
 
// mozemy albo najpierw przygotowac obiekt walidatora
$walidator = v::string()->between('a', 'c');
 
// albo tez bezposrednio uzywac w instrukcjach warunkowych, np.
if (v::numeric()->positive()->validate($cos)) echo 'prawda';
 
//i potem uzywac do sprawdzania jednej z trzech metod:
 
// zwroci tylko true albo false
$walidator->validate($cos);
 
// wypluje wyjatek z pierwszym bledem
$walidator->check($cos);
 
// wypluje wyjatek ze wszystkimi bledami
$walidator->assert($cos);

Warunków, które możemy sprawdzać jest kilkadziesiąt. Można popatrzeć po plikach. Z ciekawszych to wymieniony wyżej

between()

dla zakresu znaków,

in(array('wartosc1' , 'wartosc2))

dla dozwolonych wartości oraz konstrukcja

v::each(v::warunek())->validate(array('wartosc1','wartosc2'));

dla sprawdzenia wszystkich wartości w tablicy. Ponadto można tworzyć kompozyty różnych warunków za pomocą

v::allOf($walidator1,$walidator2);

(jeżeli wszystkie muszą przejść) oraz

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

Zwiń
Czytaj na blogu autora...