Indeksy TTL możemy tworzyć na dwa różne sposoby. Możemy spowodować usunięcie  dokumentu po określonej liczbie sekund lub o określonym przez nas czasie.

Usuwanie dokumentów po upłynięciu określonego czasu

W tym przypadku należy utworzyć indeks na polu zawierającym datę, podając czas w sekundach, po jakim dokument zostanie usunięty.

Wyobraźmy sobie następującą, uproszczoną sytuację: w naszej aplikacji chcemy udostępniać jakieś zasoby, jednak wprowadzamy limit dla adresu IP. Powiedzmy, że użytkownik może coś pobrać raz na 10 minut. W naszej bazie informacje o fakcie pobrania będziemy przechowywali w następującej kolekcji:

use downloads;
db.waiting.insert({createdAt: new Date(), ip: "111.222.333.444"});
db.waiting.insert({createdAt: new Date(), ip: "555.666.777.888"});

Jeśli chcemy aby nasze rekordy były kasowane z niej po 10 minutach wystarczy, że nałożymy następujący indeks TTL na pole z datą:

db.waiting.ensureIndex( { "createdAt": 1 }, { expireAfterSeconds: 600 } )

Po upłynięciu 600 sekund rekord zostanie automatycznie skasowany.

Usuwanie dokumentów o określonym czasie

Indeks TTL możemy także skonfigurować odwrotnie, tj. podając dokładny czas, w jakim dokument ma zostać skasowany. W tym celu należy na pole z datą ustawić indeks z wartością expireAfterSeconds ustawioną na 0:

db.premium.ensureIndex( { "expireAt": 1 }, { expireAfterSeconds: 0 } )

Jeśli data ustawiona w polu expireAt minie, to dokument zostanie automatycznie skasowany.

Kilka dodatkowych informacji

W przypadku korzystania z opisanej funkcjonalności, warto pamiętać o tym, że:

• Nie można nałożyć indeksu TTL na pole _id.
• Indeks TTL nie może być ustawiony na pole, które posiada już inny indeks.
• Dokument nie zostanie usunięty, jeśli nie będzie on posiadał zaindeksowanego pola (nie będzie w nim istniało pole z datą).
• Dokument nie wygaśnie, jeśli zaindeksowane pole nie będzie pojedynczą datą lub tablicą dat w formacie BSON.
• Indeksy TTL mogą być tylko proste (muszą składać się z jednego pola).
• Jeśli indeks TTL został nałożony na tablicę, w której są daty, to dokument wygaśnie po uwzględnieniu najwcześniejszej z nich.
• Nie można nałożyć indeksu TTL w capped collection (specjalna kolekcja, w której dane nadpisują się automatycznie).
• Nie można użyć ensureIndex() w celu zmiany parametru expireAfterSeconds.
• W przypadku tworzenia indeksu TTL typu background, dokumenty mogą być kasowane już w trakcie jego budowania. Jeśli będziemy go tworzyć jako foreground, dokumenty będą kasowane po jego zbudowaniu.
• W przypadku używania indeksu TTL na zreplikowanych bazach, zostanie on uaktywniony tylko na primary. Dane zostaną usunięte z serwerów secondary podczas synchronizacji.

Dlaczego dane nie kasują się od razu?

Przeprowadzając testy indeksów TTL z ustawionymi krótkimi czasami usunięcia dokumentów (np. kilkadziesiąt sekund) można dojść do wniosku, że nie wygasają one tak jak powinny. Dzieje się tak dlatego, że proces kasujący dane jest wywoływany co 60 sekund. Z tego względu dokumenty mogą zostać usunięte w krótkim czasie po upłynięciu terminu (działanie nie rozpoczyna się natychmiastowo).

Tworzenie patcha

Tworzenie patcha w GIT jest niezwykle proste. Powiedzmy, że chcemy wprowadzić pewną zmianę w działającą, zewnętrzną aplikację, a następnie przesłać te zmiany innemu programiście. Na początek powinniśmy stworzyć osobny branch na nasze zmiany:

git checkout -b fix-example master

Powyższe polecenie stworzy nowy branch o nazwie fix-example na podstawie gałęzi master i przełączy się na nią.

Następnie wprowadzamy wymagane poprawki i wykonujemy commit:

git add .
git commit -m "My fixes"

Teraz pozostaje już tylko wygenerowanie patcha z naszymi zmianami:

git format-patch master --stdout > fix-example.patch

Powyższe polecenie wygeneruje plik z wszystkimi zmianami w stosunku do gałęzi master.

Tworzenie patcha dla pojedynczego commita

Jeśli chcemy stworzyć osobne patche dla każdego commita, możemy to zrobić w następujący sposób:

git format-patch -2 0c4b265151e8de7416d16d447d7ac89043c75481

Pierwszy parametr oznacza, ile patchy chcemy stworzyć, a drugi początkowego commita,. Poszczególne pliki zostaną nazwane na podstawie opisu commita, np:

0001-My-fix-example.patch
0002-My-fix-examlple-2.patch

Załadowanie patcha

Ładowanie patcha jest równie proste, co jego tworzenie. Na początek możemy sprawdzić, co nowego wnosi przygotowana poprawka:

git apply --stat fix-example.patch

Wynikiem tego działania będzie lista wszystkich plików wraz z podsumowaniem zmian:

myfile1.php | 4
myfile2.php | 2
2 files changed, 3 insertions(+), 3 deletions(-)

W następnym kroku warto sprawdzić, czy załadowanie patcha uda się przeprowadzić bez konfliktów. W końcu w aplikacji mogły się już pojawić jakieś zmiany dokonane przez inne osoby:

git apply --check fix-example.patch

W przypadku konfliktów, zostaną one wyświetlone na liście, na przykład:

error: patch failed: myfile1.php:29
error: myfile1.php: patch does not apply

Natomiast w przypadku, gdy wszystko będzie możliwe do załadowania, nie powinniśmy zobaczyć żadnego komunikatu. W takim przypadku pozostaje już tylko faktyczne załadowanie naszej poprawki. Można to zrobić przy pomocy dwóch komend: git apply oraz git am. Druga z nich będzie jednak lepsza, gdyż umożliwia podpisanie patcha przez osobę, która go zaaplikowała:

git am --signoff < fix-example.patch

Po zakończeniu operacji zostanie wyświetlona lista commitów, jakie zostały wprowadzone w patchu:

Applying: my fix example

Przeglądając historię, będziemy mogli łatwo odnaleźć informację zarówno o autorze jak i osobie, która ją załadowała do repozytorium:

$ git log
commit 01ed141f907ffafea6f3f0c9947c9b78dba1bb45
Author: Marcin Fliszta <marcin.fliszta@...>
Date: Sat Nov 30 13:13:40 2013 +0100

my fix example

Signed-off-by: Marcin Fliszta <marcin.fliszta@...>

Wycofanie patcha

Gdy podczas ładowania patcha coś pójdzie nie tak jak się spodziewaliśmy, możemy łatwo go wycofać. Tryb rozwiązywania problemów jest podobny do tego, z którym mamy do czynienia podczas konfliktów.

$ git am --signoff < 0001-My-fix-example.patch
Applying: myfile1.php update
error: patch failed: myfile1.php:1
error: myfile1.php: patch does not apply
Patch failed at 0001 myfile1 update
The copy of the patch that failed is found in:
/var/www/patchexample/.git/rebase-apply/patch
When you have resolved this problem, run "git am --resolved".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

W celu wycofania naszego patcha wystarczy zastosować komendę wymienioną na końcu informacji o niepowodzeniu:

git am --abort

Przenoszenie commitów pomiędzy branchami

Jeśli widzisz dodatkowe zastosowanie opisanych tutaj rozwiązań w przypadku przenoszenia wybranych commitów pomiedzy lokalnymi branchami, to nie warto zawracać sobie tym głowy. Do tego celu GIT posiada znacznie lepsze polecenie, jakim jest cherry-pick.

Jego składnia i działanie są banalnie proste i może wyglądać następująco:

git cherry-pick 01ed141f907ffafea6f3f0c9947c9b78dba1bb45

Powyższe wywołanie spowoduje wstawienie wybranego po hashu commita do bieżącego brancha. Nie musimy oczywiście wskazywać z jakiego brancha ma być on załadowany, gdyż hash jest unikalny dla całego repozytorium. Dostępne są oczywiście różne opcje tego polecenia, można zapoznać się z nimi w dokumentacji GITa.

Jak wygląda uzycie Method chaining w praktyce?

Jest on stosowany w wielu różnych językach, a webdeveloperzy mogą go znaleźć między innymi w jQuery lub frameworkach PHP. Upraszcza to znacznie tworzenie kodu, co można zobaczyć na poniższym przykładzie:

$("p").removeClass("class")
	.addClass("another_class")
	.css("color","red")
	.fadeOut("slow");

Jak zaimplementować Method chaining w PHP?

Bardzo podobnie możemy powyższe rozwiązanie wykorzystać w PHP. Jest to niezwykle proste do osiągnięcia, wystarczy, że poszczególne wywoływane metody będą zwracały cały obiekt. Przez to nie będzie trzeba go podawać za każdym razem, lecz utworzyć odpowiedni łańcuch.

Na poniższym przykładzie przedstawiono implementację Method chaining. Jest to klasa bardzo uproszczonego kalkulatora, dzięki któremu możemy wykonywać podstawowe działania matematyczne.

class Calculator{
	private $_result = 0;

	public function __construct($value = 0) {
		$this->_result = $value;
		return $this;
	}

	public function add($value){
		$this->_result+=$value;
		return $this;
	}

	public function subtract($value){
		$this->_result-=$value;
		return $this;
	}

	public function multiply($value){
		$this->_result*=$value;
		return $this;
	}

	public function divide($value){
		$this->_result/=$value;
		return $this;
	}

	public function getResult(){
		return $this->_result;
	}
}

Implementacja Metchod chaining kryje się w wywołaniu return $this na końcu każdej metody odpowiedzialnej za działania matematyczne. Dzięki temu będzie możliwe niezwykle proste wykonanie obliczeń:

$calc = new Calculator(5);
print $calc->add(2)
		->subtract(1)
		->divide(2)
		->multiply(3)
		->getResult();

Pominięcie osobnego tworzenia obiektu

Możliwe jest także zastosowanie Method chaining bezpośrednio przy wywołaniu obiektu, dzięki czemu nie będziemy musieli tworzyć go w osobnej linii. Wystarczy w tym celu dodać do klasy Calculator statyczną metodę start(), która zwróci nam utworzony obiekt:

public static function start($value = 0){
	return new Calculator($value);
}

Dzięki takiemu rozwiązaniu możemy jeszcze bardziej uprościć wywołanie kalkulatora:

print Calculator::start(5)->add(4)->divide(3)->getResult();

Rozwiązanie problemu numerowania wierszy w MySQL jest niezwykle proste. Wystarczy zdefiniować zmienną globalną, która będzie przechowywać licznik i wyświetlić ją jako argument polecenia SELECT. Może to wyglądać w następujący sposób:

set @row = 0;
select @row := @row + 1 as "Lp.",
imie,
nazwisko
from klienci

Niestety, sytuacja zaczyna się komplikować, gdy rozbudujemy zapytanie. Wzbogacając je o złączenia, klauzulę WHERE oraz sortowania, możemy spodziewać się błędnego numerowania wierszy. Widać to na poniższym przykładzie pobierania danych dotyczących statystyk odwiedzin strony www:

SET @a:=0;
SELECT @a:=@a+1 AS "row",
IP
FROM `stats` st JOIN
`sources` so ON st.source_id = st.source_id
WHERE st.created_at BETWEEN "2011-01-01 00:000:00" AND "2011-01-01 23:59:59"
AND st.IP LIKE "1%"
AND st.source_id=1
ORDER BY st.IP

Wynik takiego wywołania będzie następujący:

row     IP
------  ---------------
77      100.113.10.222
50      100.113.10.222
23      100.113.10.222
60      104.87.121.89
33      104.87.121.89
6       104.87.121.89
[…]

Sposobem na rozwiązanie tego problemu będzie podzapytanie w klauzuli FROM. Wystarczy umieścić numerowanie wierszy w zewnętrznym zapytaniu i dodać do niego pozostałe interesujące nas kolumny, które będą pobierane z wewnętrznego zapytania, odpowiedzialnego za filtrowanie oraz sortowanie. Zapytanie SQL po modyfikacji może więc wyglądać w następujący sposób:

SET @a:=0;
SELECT @a:=@a+1, IP FROM (
SELECT st.IP
FROM `stats` st JOIN
`sources` so ON st.source_id = st.source_id
WHERE st.created_at BETWEEN "2011-01-01 00:000:00" AND "2011-01-01 23:59:59"
AND st.IP LIKE "1%"
AND st.source_id=1
ORDER BY st.IP
) AS sub

Numerowanie wierszy w wyniku powyższej modyfikacji będzie poprawne:

row     IP
------  ---------------
1       100.113.10.222
2       100.113.10.222
3       100.113.10.222
4       104.87.121.89
5       104.87.121.89
6       104.87.121.89
[...]

Od czasu wprowadzenia zmian w algorytmie minął już pewny okres czasu, można spotkać się jednak z różnymi zdaniami na temat jego efektów. Oczywiście SEO nie umarło, należy tylko bardziej słuchać Google i zwracać uwagę na jakość swoich poczynań.

Pingwin a jakość strony, czyli on-site optimization

Najważniejszą rzeczą, jaką można zauważyć po wprowadzeniu Pingwina jest to, że Google zaczyna przykładać mniejszą wagę do treści samych linków prowadzących do pozycjonowanej strony, a bardziej zwraca uwagę na ich powiązanie tematyczne oraz jakość. Wykrywanie spamu zostało znacznie poprawione, a analiza stron jest bardziej szczegółowa niż wcześniej. Warto więc jeszcze bardziej zwrócić uwagę na aspekty, które liczyły się już wcześniej:

• unikać powielania treści (duplicate content)
• unikać powtarzania designu strony (duplicate design)
• zadbać o odpowiednią ilość tekstu na podstronach
• uzupełniać tekst o grafikę, filmy
• wyróżniać słowa kluczowe w tekście (poprzez HTML a teraz także CSS)
• zadbać o natężenie słów kluczowych – nie można przesadzić, liczy się naturalność
• nie używać bloków słów kluczowych umieszczonych w stopce lub panelu bocznym, które są stworzone tylko dla Google

Strony, które zostaną uznane za spamerskie lub łamią niektóre z wytycznych, mogą się narazić na obniżenie swojej pozycji. Oczywiście dotyczy to zarówno stron pozycjonowanych, jak i tych które do nich linkują. Ważne jest to, że obniżenie przez Google siły stron linkujących, wpłynie ostatecznie na docelowy serwis.

Dlatego najważniejszą sprawą jest dbanie o jakość treści. Powinna być tworzona z myślą o użytkownikach, a nie tylko i wyłącznie o silniku wyszukiwarki. Pingwin spowodował, że Google znacznie lepiej wykrywa spam i nieodpowiednie techniki SEO. Ważne jest więc poszukiwanie linków z wysokiej jakości stron oraz zadbanie o własne zaplecze (o czym będzie mowa później).

Różnorodność linków

Teoretycznie Google lepiej traktuje strony pozycjonowane w naturalny sposób, korzystające z wite hat SEO. Oczywiście nie zawsze ci, którzy łamią te zasady dostają kary, a ich przeciwnicy są wyżej w wyniku wyszukiwania. Niemniej po Pingwinie można zauważyć, że strony, które były agresywnie linkowane na małą liczbę słów kluczowych, raczej spadały w SERPach. Co można więc zrobić, aby nasze działania SEO Gogle odbierał jako naturalne?

Na początek główne frazy po których pozycjonujemy, należy różnicować pod względem treści linków. Cześć powinna być dokładna (np. „biura rachunkowe”), ale warto korzystać także z ich różnego rodzaju odmian (np. „tanie biura rachunkowe”, „najlepsze biura rachunkowe” itp.).

Dobrym rozwiązaniem jest pozycjonowanie długiego ogona (ang. long tail), czyli większej liczby mniej popularnych fraz. Dzięki temu dla Google takie budowanie pozycji jest bardziej naturalne. Oprócz wyboru większej liczby fraz należy kierować linki na różne podstrony serwisu. W uproszczeniu, zamiast pozycjonować agresywnie stronę główną sklepu interentowego na frazę „telewizory” lepiej linkować go po frazach „telewizory LCD”, „telewizory plazmowe”, „Samsung UE40D5500″ itd. W dwóch pierwszych przypadkach link powinien kierować na odpowiednią kategorię, w ostatnim na konkretny produkt. Oczywiście należy zbudować odpowiednio duży i wartościowy zestaw takich fraz.

Warto od czasu do czasu zostawić też gdzieś link w naturalnej postaci, tak jak to robią najczęściej użytkownicy (anchor jako URL lub nazwa strony www), a nawet w postaci „kliknij tutaj” lub „odwiedź nas”.

Ministrony powiązane tematycznie

Dbanie o dobrej jakości linki nigdy nie było proste. Oczywiście zamiast ich szukać, możemy sami je stworzyć. Do tego celu warto zbudować własne serwisy zapleczowe, powiązane tematycznie z pozycjonowanym serwisem, które będą do niego linkowały. Nie jest to do końca zgodne z wytycznymi Google, jednak przynosi nadal korzyści.

Warto dobrze przyłożyć się do budowy takich serwisów z założeniem, że są one tworzone pod kątem użytkowników a nie wyszukiwarek. Należy więc zwrócić uwagę na:

• Unikalną, ciekawą, poprawną gramatycznie oraz stylistycznie treść
• Różnorodność w budowie i wyglądzie poszczególnych serwisów
• Różne rodzaje użytych CMS
• Różne IP dla poszczególnych serwisów

Takie strony powinny mieć przynajmniej około 20 podstron i co jakiś czas być aktualizowane oraz rozbudowywane o nową treść. Ogólna zasada – im bardziej naturalnie i niezwiązanie ze sobą wyglądają nasze serwisy, tym większa będzie ich siła (i mniejsza szansa na bana lub filtr). Wszyscy, którzy zastanawiają się nad budową większej sieci ministron, powinni się zapoznać ze świetnym artykułem Zgreda: Sposób linkowania dla 100 domen.

Wysokiej jakości sieci prywatnych blogów

Presell pages nie są postrzegane jako white hat SEO, jednak używanie ich w umiejętny sposób może być korzystne. Warto więc posiadać sieć prywatnych, moderowanych serwisów z dobrą jakościowo treścią. Ważne, aby linki znajdujące się w tekście były powiązane tematycznie z jak najbardziej naturalnym artykułem. W SEO liczy się często jakość a nie ilość, większą moc da kilka wysokiej jakości linków niż znacznie więcej ze spamerskich serwisów. Najlepiej by było, gdyby całe precle zostały tematycznie powiązane z pozycjonowanym serwisem. Obecnie często można spotkać takie serwisy, które przyjmują teksty tylko z określonych kategorii, na przykład zdrowie i uroda, turystyka lub komputery i Internet.

Pozyskiwanie linków zgodnie z zasadami Google

To naturalnie trudniejsze zadanie, ale może dać nam dużą korzyść. Będzie to wyśmienite uzupełnienie wszystkich pozostałych opisanych technik, które mogą być postrzegane przez Google jako nieodpowiednie.

Warto więc dbać o wysokiej jakości treści na stronach, którą użytkownicy mogą sami linkować i udostępniać innym za pośrednictwem najróżniejszych mediów. Dobrze budować pozycję eksperta, publikować teksty w branżowych serwisach lub serwisach wymiany treści. Wyśmienitym miejscem na zbieranie linków są także serwisy społecznościowe, fora dyskusyjne itp. Warto czasem samemu rozpocząć dyskusję w takich miejscach, co może dać nam nie tylko linki, ale także inne profity. Wkraczamy tu trochę w buzz marketing, niemniej jednak takie działania mogą wspomagać w dużym stopniu SEO.

Niniejszy artykuł powstał na podstawie analizy dokonanej przez serwis micrositemasters.com, Josha Bachynskiego, informacji zaczerpniętych z bloga Zgreda oraz własnych obserwacji pozycjonowanych stron.

Na czym polega błąd CVE-2012-182 zgłoszony przez De Eindbazen’a? Jeśli PHP działa w trybie CGI (np. Apache mod_cgid), możliwe jest przekazywanie dodatkowych parametrów wykonania skryptu. Niestety, z powodu błędnego przetwarzania parametrów w URL, które nie zawierają znaku „=”, umożliwia to potencjalnemu intruzowi wykonanie wielu niebezpiecznych czynności. Jedną z nich może być na przykład wyświetlenie kodu przetwarzanego skryptu, czego można dokonać, używając parametru -s w następujący sposób:

http://localhost/index.php?-s

Parametr w postaci ?-s&=1 jest jednak całkowicie bezpieczny.

Po wydaniu poprawki 5.4.2 i 5.3.12, która miała rozwiązać problem okazało się, że część systemów bazujących na PHP w konfiguracji CGI jest nadal podatna na niebezpieczeństwo. Opublikowane 8 maja wersje PHP 5.4.3 i 5.3.13 powinny ostatecznie rozwiązywać ten problem.

Ci, którzy nie mogą dokonać aktualizacji, powinni do zabezpieczenia się wykorzystać odpowiednie reguły mod_rewrite Apache. Jak podano na php.net, można skorzystać z następującego rozwiązania:

RewriteCond %{QUERY_STRING} ^[^=]*$
RewriteCond %{QUERY_STRING} %2d|\- [NC]
RewriteRule .? - [F,L]

Należy jednak uważać, gdyż powyższe reguły mogą zablokować część poprawnych Urli (np. ?top-40). Z tego względu należy je przetestować i dopasować do swoich potrzeb.

Wersja PHP 5.4.3 dodatkowo rozwiązuje problem z przepełnianiem bufora w apache_request_headers() (CVE-2012-2329). PHP 5.3 nie jest podatne na ten błąd.

Do poniższych przykładów będzie wykorzystana fikcyjna, uproszczona baza danych, zawierająca statystyki wejść na stronę www. Tabela stats zawiera dane na temat wejść i jest powiązana z tabelą sources zawierającą źródła wejść (bezpośrednie, wyszukiwarka, odnośnik).

Do wypełnienia tabeli fikcyjnymi danymi można użyć poniższej procedury:

DELIMITER $$

CREATE DEFINER=`root`@`%` PROCEDURE `randstats`(insertLimit INT)
BEGIN
DECLARE i INT DEFAULT 0;
DECLARE randIP VARCHAR(15);
DECLARE randSoudce_id INT;
DECLARE randCreated_at DATETIME;

WHILE i < insertLimit DO
SET randIP = CONCAT_WS('.', FLOOR(1 + (RAND() * 255)), FLOOR(1 + (RAND() * 255)), 
FLOOR(1 + (RAND() * 255)), FLOOR(1 + (RAND() * 255)));
SET randSoudce_id = FLOOR(1 + (RAND() * 3));
SET randCreated_at = '2010-01-01 00:00:00' + INTERVAL FLOOR(1 + (RAND() * 60*24*7*4*12*2)) MINUTE;

INSERT INTO `stats`(source_id, created_at, IP) VALUES (randSoudce_id, randCreated_at, randIP);

SET i = i + 1;
END WHILE;
END $$

DELIMITER ;

call randstats(100000);

Grupowanie względem dnia

Powiedzmy, że zależy nam na wyciągnięciu statystyk wejść na stronę www z ostatniego miesiąca, z podziałem na poszczególne dni. W tym celu wystarczy skorzystać z funkcji DATE(), która zwraca samą datę z wyrażenia typu datetime.

SELECT
DATE(created_at) AS dzien,
COUNT(*) AS ilosc
FROM stats
WHERE created_at BETWEEN "2011-01-01 00:00:00" AND "2011-01-31 23:59:59"
GROUP BY dzien
ORDER BY dzien;

Wynik wywołania zapytania będzie następujący:

dzien       ilosc
----------  ------
2011-01-01  168
2011-01-02  187
2011-01-03  190
2011-01-04  201
...

Grupowanie względem tygodnia

Oczywiście sytuacja jest analogiczna do powyższego, będziemy jednak pobierali statystyki z ostatniego roku. Do odpowiedniego grupowania potrzebna będzie funkcja DATE_FORMAT() lub YEARWEEK(). Lepiej będzie skorzystać z tej drugiej, z uwagi na lepszą wydajność.

Funkcja YEARWEEK() zwraca w MySQL sześciocyfrowy ciąg, określający rok oraz numer tygodnia. Pierwszym parametrem jest data, natomiast drugim, opcjonalnym, tryb w jakim ma działać. Określa czy tydzień zaczyna się od niedzieli, czy też od poniedziałku (domyślną wartością jest zmienna systemowa default_week_format).

SELECT
YEARWEEK(created_at) AS tydzien,
COUNT(*) AS ilosc
FROM stats
WHERE created_at BETWEEN "2011-01-03 00:00:00" AND "2011-04-31 23:59:59"
GROUP BY tydzien
ORDER BY tydzien;

Wynik wywołania zapytania będzie następujący:

tydzien  ilosc
-------  ------
201101   1320
201102   1320
201103   1321
201104   1250
...

Grupowanie względem miesiąca

W tym przypadku najlepiej będzie skorzystać z funkcji EXTRACT() z odpowiednim parametrem YEAR_MONTH, dzięki czemu otrzymamy sześcioznakowy ciąg: połączenie roku oraz miesiąca. Pobranie pogrupowanych statystyk na dany miesiąc w roku 2011 może więc wyglądać następująco:

SELECT
EXTRACT(YEAR_MONTH FROM created_at) AS miesiac,
COUNT(*) AS ilosc
FROM stats
WHERE created_at BETWEEN "2011-01-01 00:00:00" AND "2011-12-31 23:59:59"
GROUP BY miesiac
ORDER BY miesiac;

Wynik wywołania zapytania będzie następujący:

miesiac  ilosc
-------  ------
201101   5738
201102   5130
201103   5713
201104   5405
...

Grupowanie względem roku

W tym przypadku sprawa jest prosta – wystarczy wykorzystać funkcję YEAR(), która zwraca rok z przekazanej daty:

SELECT
YEAR(created_at) AS rok,
COUNT(*) AS ilosc
FROM stats
GROUP BY rok
ORDER BY rok;

Wynik wywołania zapytania będzie następujący:

rok     ilosc
------  ------
2010    66793
2011    56547

Grupowanie z uwzględnieniem typu

Na zakończenie mała ciekawostka, czyli sposób na policzenie ilości wejść na stronę z podziałem na źródła. Do tego celu wykorzystamy pierwsze zapytanie (grupowanie na dzień), wymaga ono jednak pewnej modyfikacji, w postaci odpowiedniego wywołania funkcji SUM().

Na początek należy przypomnieć, że źródła wejść w tabeli sources przedstawiają się następująco:

source_id  source_name
---------  -------------
1          bezpośrednie
2          wyszukiwarka
3          odnośnik

Tak, więc aby zliczyć wystąpienia poszczególnych źródeł w podziale na dni, należy użyć odpowiednio instrukcji CASE w połączeniu z SUM(). Widać to na poniższym przykładzie:

SELECT
DATE(created_at) AS dzien,
SUM(CASE WHEN`source_id` = 1 THEN 1 ELSE 0 END) AS bezposrednie,
SUM(CASE WHEN`source_id` = 2 THEN 1 ELSE 0 END) AS wyszukiwarka,
SUM(CASE WHEN`source_id` = 3 THEN 1 ELSE 0 END) AS odnosnik
FROM stats
WHERE created_at BETWEEN "2011-01-01 00:00:00" AND "2011-01-31 23:59:59"
GROUP BY dzien
ORDER BY dzien;

Wynik wywołania zapytania będzie następujący:

dzien       bezposrednie  wyszukiwarka  odnosnik
----------  ------------  ------------  ---------
2011-01-01  50            69            49
2011-01-02  77            47            63
2011-01-03  61            66            63
2011-01-04  62            55            84
2011-01-05  55            57            56
2011-01-06  69            64            59
...

Artykuł został oparty na tekście ze strony http://www.techfounder.net

Lista poprawek odnosi się zarówno do jądra języka, jak i niektórych rozszerzeń. Pełną listę zmian, jakie zostały dokonane w wersjach PHP 5.4.1.oraz 5.3.11, można znaleźć tutaj. Oczywiście wszystkim użytkownikom zaleca się ze względów bezpieczeństwa jak najszybsze uaktualnienie do najnowszej wersji.

Ważną zmianą, jaka ma pojawić się w najnowszej aktualizacji algorytmu Google, jest lepsze identyfikowanie spamerskich stron. Chodzi głównie o witryny, które zawierają teksty stworzone głównie pod wyszukiwarki, będące najczęściej zlepkiem słów kluczowych. Są one zazwyczaj przygotowane przez automatyczne synonimizatory, podmieniające oznaczone wyrazy w tekście czyniąc go całkowicie nieczytelnym dla normalnego użytkownika.

Zmiana algorytmu Google ma także wpłynąć na strony, zawierające niedopasowane linki. Chodzi o sytuację, w której w treść tekstu wstawione są zupełnie niezwiązane tematycznie z nim linki.

Obie powyższe sytuacje są niezwykle często spotykane w kiepskiej jakości serwisach presell page. Czy będzie to oznaczało, że po aktualizacji będą miały one problemy i stracą na sile?

Oczywiście zmiany w algorytmie mają prowadzić według Google do polepszenia pozycji w SERPach przez wartościowe serwisy. Jak radzą jego przedstawiciele, najlepiej stosować w tym celu white hat SEO. W skrócie główne zasady, przedstawiane przez Google, są następujące:

• strony powinny być tworzone dla użytkowników, a nie wyszukiwarek (np. nie należy stosować osobnej treści dla Google i odwiedzających)
• należy unikać sztuczek mających na celu podniesienie pozycji w wyszukiwarkach (np. ukryty tekst lub linki)
• nie powinno się korzystać z systemów wymiany linkami (SWL), unikać linkowania do spamerskich stron oraz „złego towarzystwa”
• nie należy używać nieautoryzowanego oprogramowania do zgłaszania stron lub sprawdzania rankingów, które wysyłają automatyczne zapytania Google (np. WebPosition Gold™)

Oczywiście warto pamiętać, aby treść na stronie była odpowiednio przygotowana i nie była kopią już istniejącej. Powinna stanowić wysokiej jakości źródło informacji i nie być przeładowana reklamami. Witryna musi być także bezpieczna dla użytkownika, nie może zawierać złośliwego oprogramowania. Powinna także w miarę szybko się ładować.

Jak zmiany w algorytmie wpłyną na wyniki wyszukiwania? Efekty będą zapewne widoczne już niebawem.

W PHP mamy do dyspozycji łącznie 9 typów zmiennych:

• 4 typy proste – logiczny, całkowity, zmiennoprzecinkowy i znakowy
• 2 złożone – tablicowy i obiektowy
• 3 specjalne – identyfikator zasobu (resorce), pusty (NULL) oraz wywoływalny (callable)

Podpowiadanie typów w PHP nie umożliwia niestety rozpoznawania wszystkich wymienionych powyżej. Od wersji 5 języka możemy to robić dla obiektów, interfejsów, tablic (od PHP 5.1), oraz parametrów wywoływalnych (PHP 5.4).

Podpowiadanie typów możemy stosować w zwykłych funkcjach, oraz metodach klas. Wystarczy w tym celu przed nazwą zmiennej podać oczekiwany typ (array, callable, nazwę konkretnej klasy lub interfejsu)

Podpowiadanie typów – obiekty

W przypadku podpowiadania typów obiektowych należy pamiętać o bardzo ważnej rzeczy: jeśli parametrem musi być konkretna klasa lub interfejs, dozwoleni są także ich potomkowie, uczestniczący w hierarchii dziedziczenia.

Gdy zostanie określony wymagany typu obiektu, przekazanie innego spowoduje powstanie błędu. Zostało to pokazane na poniższym przykładzie:

class Factory{
	public function produce(Product $product){
		print "Produkuję " . get_class($product);
	}
}

class Stock{
	/* ... */
}

class Product{
	/* ... */
}

class Car extends Product{
	/* ... */
}

class Motorbike extends Product{
	/* ... */
}

$factory = new Factory();
$stock = new Stock();
$car = new Car();
$motorbike = new Motorbike();

$factory->produce($car);
$factory->produce($motorbike);
$factory->produce($stock);

Zdefiniowane zostały klasy: Factory, Stock, Product oraz dziedziczące po nim Car oraz Motorbike. Klasa fabryki posiada zdefiniowaną jedną metodę, odpowiadającą za produkcję. Wymaga ona przekazania obiektu typu Product. Na powyższym listingu przekazano do niej natomiast dozwolone parametry wywodzące się z klasy Product, ale na koniec omyłkowo także Stock. Efekt będzie następujący:

Produkuję Car
Produkuję Motorbike
Fatal error: Argument 1 passed to Factory::produce() must be an instance of 
Product, called in typehinting.php on line 31 and defined in typehinting.php 
on line 3

Jak wspomniano już wcześniej, podpowiadanie typów w przypadku obiektów działa zarówno dla utworzonych bezpośrednio, jak i dziedziczących po określonym w definicji. Poprawne będzie więc też następujące wywołanie:

$factory = new Factory();
$product = new Product();

$factory->produce($product);

W powyższym przypadku może nie jest to do końca pożądane, jednak w praktyce częściej będziemy oczekiwali obiektów klas dziedziczących. Oczywiście, gdy tego chcemy, możemy zawęzić wymagany typ tylko do klasy pochodnej.

class Factory{
	public function produce(Car $product){
		print "Produkuję tylko samochody";
	}
}

W przypadku podpowiadania typów można stosować także wartości domyślne. Jeśli w naszej fabryce przewidujemy strajk, możemy posłużyć się następującą definicją:

class Factory{
	public function produce(Product $product = null){
		print "Produkuję" . get_class($product);
	}
}

$factory = new Factory();
$factory->produce();

Analogicznie do powyższych informacji, podpowiadanie typów może być używane także w przypadku interfejsów. Wystarczy określić, że parametr musi implementować jeden ze zdefiniowanych. Aby zobrazować tą możliwość, dokonamy pewnych zmian klas z pierwszego przykładu. Otóż w naszej fabryce w Indiach zamierzamy wyprodukować limitowaną wersję samochodu, o zwiększonej mocy silnika. Klasa fabryki otrzyma więc dodatkową możliwość produkcji, a specyfikacja samochodu zostanie odpowiednio zmodyfikowana poprzez implementację interfejsu (pominięto tu klasy zdefiniowane w pierwszym przykładzie):

interface limitedEdition{
	public function engineImprovements();
}

class carSpecial extends car implements limitedEdition{
	public function engineImprovements(){
		print "Zwiększona moc silnika";
	}
}

class FactoryIndia extends Factory {
	public function produceSpecialCar(limitedEdition $car){
		print "Produkuję limitowaną wersję samochodu.";
	}
}

$factoryIndia = new FactoryIndia();
$car = new car();
$carSpecial = new carSpecial();

$factoryIndia->produceSpecialCar($carSpecial);
$factoryIndia->produce($car);
$factoryIndia->produceSpecialCar($car);

Efekt wywołania kodu będzie następujący:

Produkuję limitowaną wersję samochodu.
Produkuję Car
Fatal error: Argument 1 passed to FactoryIndia::produceSpecialCar() must implement 
interface limitedEdition, called in typehinting.php5 on line 43 and defined in 
typehinting.php on line 32

Jak widać, najpierw wyprodukowano edycję limitowaną samochodu przy użyciu nowej linii produkcyjnej, a następnie powrócono do wersji zwykłej. W kolejnym kroku, w wyniku błędu pracownika, uruchomiono jednak ponownie zmodyfikowaną linię produkcyjna dla wersji podstawowej samochodu, co oczywiście zostało szybko wychwycone przez inspektorów kontroli jakości.

Podpowiadanie typów – tablice

Sytuacja jest analogiczna do opisywanych powyżej możliwości w przypadku obiektów. Poniższy przykład obrazuje w jaki sposób zastrzec, aby zdefiniowana funkcja akceptowała jako parametr tylko tablicę:

function needArray(array $param){
	print_r($param);
}

$array = array(1, 2, 3);

needArray($array);

Możemy także określić domyślą tablicę, dzięki czemu możliwe będzie wywołanie funkcji bez żadnego parametru:

function needArray(array $param = array(7, 8, 9)){
	print_r($param);
}

Podpowiadanie typów – callable

Jest to najnowsza możliwość podpowiadania typów, wprowadzona w PHP 5.4. Dzięki niej można określić, że parametr przekazywany do funkcji lub metody musi być wywoływalny. Ma to zastosowanie w przypadku stosowania callbacków oraz funkcji anonimowych.

function myFunction(callable $callback) {
	echo "Wywołuję callback: " . $callback();
}

myFunction(function() { return 'Witaj!'; });

Podsumowanie

Jak widać na przedstawionych przykładach, wykorzystanie podpowiadania typów jest niezwykle przydatne i znacznie upraszcza tworzony kod. Nie musimy aż tak wnikliwie sprawdzać przekazywanych argumentów przy pomocy is_array() lub instanceof. Mam nadzieję, że w type hinting w kolejnych wersjach PHP zostanie rozszerzone o typy proste.