Od pewnego czasu umysły geeków na całym świecie zaprząta Node.js – technologia pozwalająca uruchomić JavaScript po stronie serwera. Szał na punkcie Node.js na tyle jest duży, iż nawet Microsoft go dostrzegł i zaoferował swoją pomoc w umożliwieniu korzystania z niego w systemie operacyjnym Windows. W efekcie dwa dni temu wydana została wersja 0.5.0, która podobno o wiele lepiej radzi sobie z Windowsem. Nie mogąc się doczekać na oficjalnego exe-ka, zakasałem rękawy i sam sobie skompilowałem Node.js na Windowsie. I wiecie co? To działa!

Okazuje się, że instalacja wcale taka straszna nie jest, a Windows po zainstalowaniu kilku drobiazgów doskonale sobie radzi w kompilowaniu aplikacji ze źródeł. Zacznijmy od początku.

1. Najpierw zainstalujcie Git for Windows – http://code.google.com/p/msysgit/
2. Następny w kolejce jest Python – http://www.python.org/download/releases/. W moim przypadku zadziałał w wersji 2.7.2. Innych nie sprawdzałem. Nie wiem czy będzie możliwe zainstalowanie Node.js korzystając z Pythona w wersji 3, więc nie ryzykujcie i zainstalujcie 2.7.
3. Ostatni do instalacji jest MinGW – http://www.mingw.org/.

   W przypadku MinGW ważne jest aby podczas instalacji zaznaczyć wszystkie możliwe checkboxy poza kompilatorami Fortran i ObjC (chyba, że planujecie kompilować aplikacje napisane w tych językach).

4. Bardzo ważne jest, aby dodać do zmiennej środowiskowej Path ścieżki do niezbędnych aplikacji. W tym celu w panelu sterowania wpisujemy w wyszukiwarkę (prawy górny róg) zaawansowane ustawienia systemu i klikamy w link, który się pojawi. Powinniśmy ujrzeć takie oto okno.

   

   Klikamy w przycisk Zmienne środowiskowe i odnajdujemy zmienną Path, do której musimy dodać miejsce, w którym mamy zainstalowanego Pythona, Gita oraz MinGW. W moim przypadku będą to C:\Python27, C:\Program Files\Git\bin, C:\MinGW\bin. Pamiętajcie, że kolejne wartości w zmiennej Path należy oddzielić od siebie średnikiem.

5. Powoli zbliżamy się ku końcowi. Jedyne co pozostało, to pobranie Node.js oraz jego skompilowanie. W tym celu udajemy się na stronę projektu – http://nodejs.org/ i pobieramy najaktualniejszą wersję. Ja zdecydowałem się na niestabilną wersję 0.5.0 ze względu na lepsze działanie pod Windowsem.
6. Opis kompilacji znajdziemy pod adresem https://github.com/joyent/node/wiki/Building-node.js-on-mingw. Wygląda on następująco:

• uruchamiamy MinGW Shell (wiersz poleceń)
• przechodzimy na dysk C, czyli cd /c
• jeśli chcemy skorzystać ze stabilnej wersji Node.js, klonujemy repozytorium Git – git clone https://github.com/joyent/node.git
• jeśli zależy nam na korzystaniu z najnowszej niestabilnej wersji, wówczas tworzymy na dysku C katalog o nazwie node i kopiujemy do niego zawartość pobranego archiwum (http://nodejs.org/#download)
• przechodzimy do katalogu node – cd /c/node
• wykonujemy skrypt konfiguracji – ./configure –without-ssl Ważne jest dodanie opcji –without-ssl. W większości przypadków nie będziemy korzystać z SSL, więc nie ma sensu doinstalowanie kolejnych aplikacji
• na koniec wykonujemy make Zajmie to dobrych kilka minut (im lepszy sprzęt, tym szybciej się wykona). Przez ekran przelecą nam tysiące robaczków i najbardziej wyczekiwany komunikat ‘build’ finished successfully.

Już. Node.js jest zainstalowany. W celu szybkiego przetestowania czy działa, wpisujemy node i cieszymy, że działa. Ważne jest aby polecenie node wykonać w katalogu, w którym zainstalowaliśmy Node.js. Ewentualnie możemy dodać kolejną wartość do zmiennej środowiskowej Path.

Jeśli chcielibyśmy sprawdzić jak działa serwer www oparty o Node.js, wystarczy, że napiszemy prosty skrypt JavaScript i wskażemy, że chcemy go wykonać.

Przykładowy kod, który znajdziemy w dokumentacji wygląda następująco:

var http = require('http');

http.createServer(function (request, response) {
	response.writeHead(200, {'Content-Type': 'text/plain'});
	response.end('Hello World\n');
}).listen(8124);

console.log('Server running at http://127.0.0.1:8124/');

Po wykonaniu polecenia node /c/Users/batman/Desktop/server.js, gdzie /c/Users/batman/Desktop/server.js powinniście zamienić na ścieżkę, w której zapisaliście swój plik, w konsoli pojawi się komunikat Server running at http://127.0.0.1:8124/. Po wpisaniu do przeglądarki adresu z komunikatu ujrzymy Hello World.

Co dalej? Przede wszystkim dokumentacja – http://nodejs.org/docs/ i dużo wolnego czasu.

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

Zwiń
Czytaj na blogu autora...

Jeśli przyjdzie Wam kiedykolwiek mierzyć się z tworzeniem layoutu na wiele urządzeń, tytułowy Less Framework będzie dla Was bardzo pomocny. Tak naprawdę to jest to tylko kilka wierszy kodu CSS, korzystającego z Media Queries, technologii pozwalającej na zastosowanie różnych reguł CSS w zależności od zadanych parametrów (np. szerokości ekranu).

Twórcy Less Frameworka Ameryki nie odkryli i jedyne co zrobili, to przygotowali cztery szerokości layoutu, odpowiadające desktopowi, tabletowi oraz urządzeniom mobilnym (telefonom) o dużej i małej rozdzielczości. Domyślną szerokością jest oczywiście desktop, dzięki czemu przeglądarki niewspierające Media Queries, poprawnie wyświetlą zawartość strony.

Zastosowanie frameworka jest banalnie proste i sprowadza się do dodania wygenerowanych reguł CSS do naszego pliku ze stylami (ewentualnie dodania jako osobnego pliku). I to wszystko. Nie musimy dodawać do kodu specjalnych znaczników, klas, placeholderów i innych dziwnych konstrukcji.

Dokładny opis frameworka oraz generator kodu CSS znajdziecie na stronie projektu – lessframework.com. Pamiętajcie, że wygenerowany kod jest tylko szkieletem, a nie wyrocznią i można go dowolnie modyfikować w zależności od własnych potrzeb.

W przypadku wielu programów ich twórcy chwalą swoje produkty jako działające bezbłędnie, mimo nieustannych prób użytkownika skierowanych w stronę zakłócenia tego błogostanu. O ile zdecydowana część tychże spełnia wspomniane warunki, o tyle kosztem osiągnięcia takiego celu jest głównie poprawność działania wyłącznie w zakresie podstawowych funkcji. Jeśli użytkownik zechce zrobić coś bardziej zaawansowanego - wtedy zaczynają [...]

Podczas swojej już kilkuletniej pracy zawodowej przy tworzeniu aplikacji internetowych, niejednokrotnie musiałem implementować różnego rodzaju systemy kontroli dostępu. Jedne były proste, drugie bardziej skomplikowane, nie mniej jednak każda aplikacja, którą rozwijałem takowy posiadała.

System kontroli dostępu zwykle opiera się na dwóch założeniach:

1. istnieją zasoby do których należy ograniczyć dostęp
2. ograniczenia dostępu przypisywane są wg ról użytkowników w systemie

Powyższy opis dokładnie odzwierciedla ideę, która leży za każdym rozwiązaniem typu ACL (ang. Access Control List). Zapewne większość z Was miała styczność z różnymi bibliotekami wspomagającymi tworzenie takich list, jak chociażby Zend_Acl z ZF.

W niniejszym artykule pragnę zaprezentować alternatywne rozwiązanie, luźno inspirowane filozofią DDD (ang. Domain Driven Design) i OOD (ang. Object Oriented Design) oraz pokazać gdzie drzemie potencjalna siła systemu typów.

By dobrze zrozumieć całą ideę należy wpierw zadać sobie pytanie „czym jest system typów” ?

Wikipedia definiuje system typów w następujących słowach

W językach programowania system typów może być zdefiniowany jako system klasyfikacji wyrażeń w zależności od rodzajów wartości, jakie one generują. Każdej obliczonej wartości przypisywany jest pewien typ, który jednoznacznie definiuje, jakie operacje można na niej wykonać. Śledząc przepływ wartości, system typów stara się udowodnić, że w programie występuje poprawne typowanie, tzn. nie dochodzi do sytuacji, w której na wartości określonego typu próbujemy wykonać niedozwoloną operację.

W prostych słowach można by powiedzieć, że system typów jest pewnym zbiorem reguł, dzięki którym możemy narzucić takie ograniczenia (constraints) w naszym programie, że będzie on „poprawny”. Oprócz tej definicji, w zorientowanym obiektowo języku programowania, dzięki systemowi typów, możemy kompleksowo opisywać rzeczywistość dokonując jej „klasyfikacji”.

Idąc dalej tym tokiem myślenia, jeżeli przestaniemy przez chwilę traktować elementy systemu typów czysto pragmatycznie – jako narzędzia do upychania kodu i poszukamy dla nich analogii w świecie rzeczywistym, to możemy dość do następujących wniosków:

• klasa – opisuje pewną grupę realnych obiektów
• interfejs – opisuję umiejętności obiektu
• klasa abstrakcyjna – jest szerszym określeniem dla pewnej grupy klas

Jak to się ma do rzeczywistości ? Prześledźmy to na przykładzie klasyfikacji zwierząt:

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

Zwiń
Czytaj na blogu autora...

Podstawowym elementem wykorzystywanym podczas tworzenia aplikacji w PHP są klasy. Tworzenie strukturalnego kodu od dłuższego czasu jest passé, a każdy kto publicznie przyznaje się do tego procederu, staje się ofiarą “ewangelistów obiektowości”. Trzeba przyznać, iż twórcy PHP zadali sobie sporo trudu, aby programowanie obiektowe w PHP nie było powodem do kpin i od piątej wersji języka dodają coraz to nowe usprawnienia wspomagające obiektówkę. Odkąd zacząłem poznawać Ruby (oraz Railsy), zaczynam powoli dochodzić do wniosku, iż OOP w PHP jest nieco przekombinowane. Zwłaszcza w kontekście tworzenia aplikacji internetowych.

Tworzenie klasy

W obu językach tworzenie klasy wygląda bardzo podobnie.

<?php
class Foo
{
}

class Foo
end

W przypadku Ruby ważne jest aby nazwa klasy zaczynała się wielką literą. W przeciwnym wypadku zgłoszony zostanie błąd.

Dodawanie metod

Dodawanie metod do klasy również zbytnio się nie różni.

<?php
class Foo
{
	public function bar()
	{
	}
}

class Foo
	def bar
	end
end

W obu językach istnieją modyfikatory widoczności metod. Zarówno w PHP jak i w Ruby metoda domyślnie jest publiczna, czyli można ją wywołać z dowolnego miejsca w kodzie. Zasadniczą różnicą jest sposób określania widoczności metod. W PHP można to zrobić tylko i wyłącznie podczas deklarowania metody, Ruby natomiast pozwala zdefiniować widoczność na dwa sposoby.

Pierwszym sposobem jest użycie modyfikatora widoczności między metodami. Wszystkie metody będą posiadały widoczność określoną modyfikatorem, pod którym się znajdują. Modyfikator obowiązuje do końca klasy lub do definicji kolejnego modyfikatora.

class Foo
	def bar
	end

	protected

	def baz
	end

	private

	def barbaz
	end
end

Drugim sposobem określenia widoczności metod jest wypisanie po modyfikatorze dostępu metod, oddzielonych przecinkami. W tym sposobie ważne jest aby deklaracja widoczności znajdowała się po metodzie. Należy również pamiętać, aby nazwę metody zapisać jako symbol, czyli poprzedzić ją dwukropkiem.

class Foo
	def bar
	end

	def baz
	end

	def barbaz
	end

	protected :baz
	private :barbaz
end

Właściwości

W obu językach możemy dodać do klasy właściwości. W PHP są to po prostu właściwości lub właściwości statyczne. Ruby określa je jako zmienne instancji (obiektu) oraz zmienne klasy. W przypadku PHP właściwości posiadają takie same zasady określania widoczności jak metody. Z kolei w Ruby zmienne instancji oraz klasy są niewidoczne poza obiektem/klasą.

<?php
class Foo
{
	public $publiczna;
	protected $chroniona;
	private $prywatna;

	public static $publicznaStatyczna;
	protected static $chronionaStatyczna;
	private static $prywatnaStatyczna;
}

class Foo
	@zmienna_instancji
	@@zmienna_klasy
end

Settery i gettery

W PHP dostęp do właściwości odbywa się przy pomocy ręcznie tworzonych metod, tzw. setterów i getterów. Od biedy można skorzystać z magicznych metod, jednak i tak wymagają one od programisty napisania sporo kodu. Ruby oferuje dwa sposoby tworzenia setterów i getterów – tradycyjny, polegający na napisaniu dwóch metod do każdej zmiennej obiektu/klasy oraz akcesory – dynamiczne generowanie wymaganych metod dla wskazanych zmiennych. Zobaczmy najpierw tradycyjny sposób.

<?php
class Foo
{
	protected $chroniona;

	public function getChroniona()
	{
		return $this->chroniona;
	}

	public function setChroniona($value)
	{
		$this->chroniona = $value;
	}
}

class Foo
	@zmienna_instancji

	def zmienna_instancji
		@zmienna_instancji
	end

	def zmienna_instancji= value
		@zmienna_instancji = value
	end
end

Warto tutaj wspomnieć o dwóch konwencjach przyjętych w języku Ruby. Po pierwsze – wynik ostatniej instrukcji metody jest automatycznie zwracany (dlatego nie jest wymagane słowo return). Po drugie, przyjęło się, iż setter kończy się znakiem równości (w Ruby jest to znak jak każdy inny). Nie jest to wymagane, ale warto trzymać się przyjętych konwencji. Warto również wiedzieć, że możemy pomijać nawiasy zarówno w deklaracji metody, jak i jej wywołaniu. Zapis metody z nawiasami wyglądałby następująco:

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

Zwiń
Czytaj na blogu autora...

W karierze programisty ważne jest, aby ciągle rozwijał się poprzez lekturę różnego rodzaju materiałów dotyczących technologii, z jakich korzysta w pracy. Dlatego w serii Linkdump pojawiają się serie linków dotyczących narzędzi wykorzystywanych podczas tworzenia stron internetowych. Czasem jednak warto też spojrzeć na inne artykuły, pozwalające na wzniesienie się ponad typowe problemy z kodem i zobaczenie [...]

Stawiałem już projekty oparte na frameworku Kohana 3 na różnych serwerach. Jak dotąd zawsze działał mi plik .htaccess o treści: # Turn on URL rewriting RewriteEngine On   # Installation directory RewriteBase /   # Protect application and system files from being viewed RewriteRule ^(?:application|modules|system)\b - [F,L]   # Allow any files or directories that [...]