Zaosoby Amazon S3 we własnej domenie

O samym Amazon S3 nie będę się rozwodził gdyż już nie raz pisałem o tej usłudze. Generalnie jest to bardzo wydajna usługa hostingu plików w chmurze amazona.

Problem

Standardowe URLe prowadzące do zasobów zgromadzonych na serwerach europejskich wyglądają następująco:

http://UNIQUE-BUCKET-NAME.s3-external-3.amazonaws.com/katalog/plik.jpg

Gdzie UNIQUE-BUCKET-NAME to unikalna w skali globalnej nazwa nadawana przez dewelopera.

Powyższy adres jest bardzo długi i nie wygląda zbyt przyjaźnie. Jeżeli komuś zależy na pewnych walorach estetycznych to pewnie wolałby zmienić ten adres na:

http://subdomena.domena.pl/katalog/plik.jpg

Rozwiązanie

Posłużę się przykładem, gdyż taki przekaz będzie najprostszy i najlepiej rozumiany. Załóżmy, że posiadamy domenę lorem.pl, wszystkie statyczne pliki hostujemy na Amazon i chcemy je widzieć pod subdomeną static.lorem.pl.

W Amazon S3 tworzymy bucket (jeżeli już mamy utworzony to zmieniamy nazwę) o nazwie identycznej do subdomeny czyli static.lorem.pl.

Następnie tworzymy rekord CNAME dla subdomeny static.lorem.pl i ustawiamy go na „s3-external-3.amazonaws.com.” (tak, musi być kropka na końcu). Rekord CNAME można ustawić w panelu administracyjnym dostarczonym przez firmę hostingową, jeżeli nie posiadacie takiej opcji to musicie przesłać dyspozycję na support.

Koniec, zmiany nie będą widoczne od razu, należy poczekać godzinę, maksymalnie kilka godzin, pliki wgrane na Amazon powinny być widoczne z poziomu subdomeny. Należy też pamiętać, aby po wgraniu plików na Amazon ustawić plikom odpowiednie ACL (prawa dostępu). W CloudBerry: PPM na bucket->ACL->ACL Settings->Public->OK

UPDATE z ORDER BY w jednym zapytaniu na przykładzie orderingu danych

Wstęp

Mamy przykładową tabelę z userami:

DROP TABLE users;
CREATE TABLE users(
	id SERIAL PRIMARY KEY,
	name VARCHAR(50),
	created TIMESTAMP DEFAULT NOW()
);

INSERT INTO users(name) VALUES('Marcin');
INSERT INTO users(name) VALUES('Bartek');
INSERT INTO users(name) VALUES('Agnieszka');
INSERT INTO users(name) VALUES('Dominika');

Na tabeli wykonywane były wielokrotnie operacje INSERT/UPDATE/DELETE przykładowo:

UPDATE users SET name = 'Ania' WHERE name = 'Bartek';
UPDATE users SET name = 'Dalia' WHERE name = 'Marcin';
DELETE FROM users WHERE name = 'Ania';

Zatem SELECT bez orderu wyświetli nam dane posortowane względem kolejności modyfikacji:

SELECT * FROM users;

psql=> select * from users;
 id |   name    |          created
----+-----------+----------------------------
  3 | Agnieszka | 2009-12-19 10:41:49.324851
  4 | Dominika  | 2009-12-19 10:41:49.958792
  1 | Dalia     | 2009-12-19 10:41:49.297223
(3 rows)

W interface aplikacji chcemy oprogramować własną obsługę kolejności rekordów. Dodajemy zatem kolumnę, która będzie obsługiwać tą funkcjonalność.

ALTER TABLE users ADD COLUMN order_id INTEGER;

Problem

Musimy teraz uzupełnić kolumne order_id o poprawne wartości. Kolejność orderu danych, które znajdują się w bazie powinna być kolejności wprowadzania tych danych do tabeli (czyli zgodna z kolejnością pola id).

Aby zrealizować poprawne uzupełnienie orderu tworzymy pomocniczą sekwencję, która wykorzystamy do wygenerowania kolejnych liczb do orderu:

DROP SEQUENCE order_id_seq;
CREATE SEQUENCE order_id_seq;

Wykonujemy oczywiste zapytanie przypisujące rekordom z tabeli users kolejne wartości sekwencji:

UPDATE users SET order_id = NEXTVAL('order_id_seq');  

Niestety przez to, że dane nie były ustawione w dobrej kolejności ORDER ustawiony jest niepoprawnie.

psql=> SELECT * FROM users;
 id |   name    |          created           | order_id
----+-----------+----------------------------+----------
  3 | Agnieszka | 2009-12-19 10:41:49.324851 |        1
  4 | Dominika  | 2009-12-19 10:41:49.958792 |        2
  1 | Dalia     | 2009-12-19 10:41:49.297223 |        4
(3 rows)

Rozwiązanie

Aby UPDATE poprawnie ustawił kolejność orderu należy nieco zmodyfikować zapytanie i nadać danym z tabeli users odpowiednią kolejność.

W tym celu tworzymy podzapytanie sorted_ids, w którym poprzez ORDER BY ustalamy kolejność rekordów, które następnie w zapytaniu nadrzędnym zostaną zmodyfikowane właśnie w tej kolejności.

UPDATE users
	SET order_id = correct_order_id
FROM
	(
	SELECT 
		id, nextval('order_id_seq') as correct_order_id
	FROM
		users
  	ORDER BY 
		id ASC
	) as sorted_ids
WHERE
	users.id = sorted_ids.id; 

select * from users order by order_id;

Jak widać dane zostały pięknie zorderowane:

psql=> select * from users order by order_id;
 id |   name    |          created           | order_id
----+-----------+----------------------------+----------
  1 | Dalia     | 2009-12-19 10:41:49.297223 |        1
  3 | Agnieszka | 2009-12-19 10:41:49.324851 |        2
  4 | Dominika  | 2009-12-19 10:41:49.958792 |        3
(3 rows)

Przy okazji wspomnę, że w aplikacji łatwiej obsłużyć ordering odwrotny, tzn. wiersze, które posiadają największą wartość order_id są na czele a nie na końcu listy. Przy takim podejściu przy wstawianiu nowego rekordu pole order_id powinno mieć wartość MAX(order_id) + 1. Dla orderingu odwrotnego należy zmienić w podzapytaniu kolejność sortowania z id ASC na id DESC.

Należy także dbać o to, aby przy usunięciu rekordu prenumerować order_id wszystkich rekordów, które znajdują się ‚nad nim’ o -1.

Usunięcie nieużywanych tagów z bazy WordPress’a

Czasami zachodzi potrzeba „ręcznego” kasowania postów z WordPress’a, jako że system ten działa na MySQL MyISAM to nie wspiera kaskadowego kasowania zależnych danych.

Skasowanie postów jest stosunkowo proste:

DELETE FROM wp_posts WHERE conditions;

Trudniejsza sprawa jest ze skasowaniem tagów. Na necie znalazłem poniższe zapytanie, działa wyśmielicie:

DELETE a,b,c
FROM
	wp_terms AS a
	LEFT JOIN wp_term_taxonomy AS c ON a.term_id = c.term_id
	LEFT JOIN wp_term_relationships AS b ON b.term_taxonomy_id = c.term_taxonomy_id
WHERE (
	c.taxonomy = 'post_tag' AND
	c.count = 0
	);

Czasami jednak pole „count” w relacji „wp_term_taxonomy” zawiera niepoprawne dane (liczbę większą od 0), wtedy nieużywane tagi musimy zidentyfikować poprzez LEFT JOINa z warunkiem ID IS NULL. Poniżej zapytanie wyświetlające nieużywane tagi.

SELECT DISTINCT wp_terms.slug FROM wp_terms wt
	INNER JOIN wp_term_taxonomy wtt ON wt.term_id=wtt.term_id
	INNER JOIN wp_term_relationships wtr ON wtr.term_taxonomy_id=wtt.term_taxonomy_id
	LEFT JOIN wp_posts wp ON wp.ID=wtr.object_id
WHERE
	taxonomy='post_tag'
AND 
	ID IS NULL
AND 
	NOT EXISTS(SELECT * FROM wp_terms wt2
                INNER JOIN wp_term_taxonomy wtt2 ON wt2.term_id=wtt2.term_id WHERE wtt2.parent=wt.term_id)
ORDER BY name

Aktualny czas a transakcja w PostgreSQL

Ostatnio miałem ciekawy case’ik – musiałem w obrębie jednej transakcji zmienić dane rekordów. Wszystko odbywało się w kilku funkcjach plpgsql, funkcje mogły się wywoływać rekurencyjnie w triggerach a zmiany dotyczyły między innymi pól typu TIMESTAMP. Wartości pól TIMESTAMP rekordów były zmieniane i ich zmiany automatycznie wpływały na w działanie skryptu.

Jakież było moje zdziwienie gdy skrypt nie chciał działać, a wszystkie rekordy miały taką zamą wartość pola typu TIMESTAMP. Otóż okazało się, że po rozpoczęciu transakcji funkcje zwracające aktualny czas:

SELECT CURRENT_TIME;
SELECT CURRENT_TIMESTAMP;
SELECT NOW();

przestały zwracać aktualny czas a zamiast tego czas rozpoczęcia transakcji.

I o dziwo jest to rzeczywiście poprawne działanie. Na stronie http://www.postgresql.org/docs/8.3/static/functions-datetime.html można przeczytać:

Since these functions return the start time of the current transaction, their values do not change during the transaction. This is considered a feature: the intent is to allow a single transaction to have a consistent notion of the „current” time, so that multiple modifications within the same transaction bear the same time stamp.

Zatem wyjściem z tego problemu jest użycie postgres’owej funkcji timeofday() i zrzutowanie jej wyniku na TIMESTAMP, realizyje to zapytanie:

SELECT cast( timeofday() AS timestamp);

Edit: zamiast timeofday() można uzyć funkcji clock_timestamp(), która zwraca date w postaci TIMESTAMP’a

SELECT clock_timestamp();

Dla ciekawości sprawdziłem jak zachowują się inne dialekty SQL i okazało się, że zarówno MySQL jak i MSSQL realizują tą sytuację odmniennie niż PostgreSQL, zatem:

  • MySQL – w transakcji zwracany jest bieżący czas (nie czas rozpoczęcia transakcji)
  • MSSQL – w transakcji zwracany jest bieżący czas (nie czas rozpoczęcia transakcji)
  • PgSQL – w transakcji zwracany jest czas rozpoczęcia transakcji

Sztuczki w wordpress’ie: przeciążanie standardowych funkcji dostępnych w szablonie

Gdy programujemy w szablonie skórki WordPress’a możemy korzystać z całej masy funkcji dostępnych w engine WordPress’a. Niektóre z nich zwracają wartości, inne od razu drukują na ekran, zwykle są parametryzowane i możliwość konfiguracji jest wystarczająco duża.

Problem

Niestety z czasem zawsze przychodzi pewne ‚ale’… chcielibyśmy aby standardowa funkcja wordpressa działała minimalnie inaczej. Zatem musimy zmodyfikować jej kod… ale stop nie możemy tak bezczelnie nadpisywać funkcji wordpress.Takie hamskie haki są niedopuszczalne z kilku powodów:

  • Utrudniamy przyszłe aktualizacje, po każdej aktualizacji będziemy musieli pamiętać aby w pliku XXX w linii YYY wstawić swojego hacka.
  • Ta sama funkcja może być wywoływana w innym pliku szablonu, może to powodować błędne/niechciane działanie. Pozatym gdy zmienimy skórkę na inną to hack pozostanie dalej mimo, że już go nie będziemy potrzebować
  • Hack’owanie kodu jakichkolwiek bibliotek/frameworków czy takich gotowych kombajnów jak wordpress jest sprzeczne z zasadami programowania.

Zatem jak sobie z tym problemem poradzić?

Wszelkie gotowe rozwiązania powinno się rozszerzać nie modyfikując przy tym źródeł samej głównej aplikacji. Jeżeli takie rozszerzenie jest nie możliwe to oznacza, że aplikacja została źle napisana i należy poszukać innej rozszerzalnej.

Czy rozszeżać funkcje w WordPress?

Oczywiście. Posłużymy się w tym celu trochę zapomnianym plikiem szablonów: functions.php. Jeżeli plik functions.php nie istnieje w katalogu głównym naszej skórki to go tworzymy. Plik ten jest automatycznie ładowany wraz z uruchomieniem WordPress’a, można w nim umieszczać swoje dedykowane dla skórki funkcje oraz jak w naszym przypadku funkcje speudo przeciążające.

Zwykle w szablonach nie ma tego pliku, także świadomość programistów wordpress’owych na temat jego jest niewielka. Zatem radze sobie zapamiętać o takiej możliwości!

Dobra, a więc załóżmy, że chcemy zmodyfikować działanie funkcji the_content_rss. Tworzymy zatem w pliku functions.php funkcję my_the_content_rss.

function my_the_content_rss($more_link_text='(more...)', $stripteaser=0, $more_file='', $cut = 0, $encode_html = 0) {
	global $id;

	ob_start();
	the_content_rss('', $stripteaser, $more_file, $cut, $encode_html);
	$bufferContent = ob_get_contents();
	ob_end_clean();

	$bufferContent = preg_replace( '/\.\.\.\s*$/', '', $bufferContent );
	$bufferContent .=  '<span class="read-on"><a href="'. get_permalink() . "#more-$id\" class=\"more-link\">$more_link_text</a></span>";
	
	print $bufferContent;
}

Funkcja my_the_content_rss musi przyjmować co najmniej takie parametry parametry jak oryginalna funkcja the_content_rss. Wywołuje oryginalną funkcję, jako że the_content_rss nie zwraca wartości tylko drukuję ją na ekran musimy zatem poprzez ob_start() włączyć buforowanie, od tej pory wszystkie dane, które miały być drukowane są zapisywane w buforze, następnie poprzez ob_get_contents() odczytujemy ten bufor i kończymy buforowanie ob_end_clean().

Teraz mając w zmiennej $bufferContent wynik działania oryginalnej funkcji możemygo dostosować do naszych indywidualnych wymagań w przykładzie jest to wycięcie „…” oraz wstawienie linka do szczegółów posta.

Tyle. Następnie w szablonie w miejscach, w których potrzebujemy niestandardowy wygląd/dane szablonu wywołujemy zamiast the_content_rss nowo stworzoną funkcję my_the_content_rss.

Sortowanie względem pola nie będącego w DISTINCT ON

Problem:
Chcemy wyświetlić jedynie unikalne rekordy względem konkretnego pola/pól i posortować innym polu. W naszym przykładzie chcemy otrzymać zestawienie id_user – ostatnie logowanie

Posiadane dane:
Tabela z datami logowań użytkowników aplikacji w tabeli postaci:

CREATE TABLE logs(
id SERIAL PRIMARY KEY, -- unikalny klucz główny
id_user INTEGER, -- klucz obcy tabeli użytkowników
date TIMESTAMP -- data logowania
);

Przykładowe rekordy:

INSERT INTO logs(id_user,date) VALUES(1,'2008-01-01');
INSERT INTO logs(id_user,date) VALUES(1,'2008-01-01');
INSERT INTO logs(id_user,date) VALUES(4,'2008-01-01');
INSERT INTO logs(id_user,date) VALUES(2,'2008-01-01');
INSERT INTO logs(id_user,date) VALUES(3,'2008-04-01');
INSERT INTO logs(id_user,date) VALUES(7,'2008-04-01');
INSERT INTO logs(id_user,date) VALUES(1,'2008-05-01');
INSERT INTO logs(id_user,date) VALUES(4,'2008-05-01');
INSERT INTO logs(id_user,date) VALUES(5,'2008-06-01');
INSERT INTO logs(id_user,date) VALUES(5,'2008-08-01');
INSERT INTO logs(id_user,date) VALUES(7,'2008-10-01');

Błędne zapytanie nr 1:
W pierwszym momencie wielu początkujących programistów pomyśli o zapytaniu:

SELECT
 DISTINCT ON (id_user)
 *
FROM
 logs
ORDER BY
 date DESC;

Niestety nie jest to poprawne zapytanie, postgres wyrzuci błąd:

ERROR:  SELECT DISTINCT ON expressions must match initial ORDER BY expressions

Oznacza to, że pola, które zawiera klauzula ORDER BY muszą się znaleźć na początku klauzuli DISTINCT ON.
W tym przypadku poprawne zapytanie musiało by zawierać DISTINCT ON (date, id_user).
Niestety wtedy nie dostaniemy pożądanego rezultatu (unikalność po kolumnie id_user) gdyż badana będzie
unikalność względem dwóch pól.

Błędne zapytanie nr 2:

SELECT
 *
FROM
 (SELECT
  DISTINCT ON (id_user)
  *
 FROM
  logs
) AS sub
ORDER BY
 sub.date DESC;

Idąc tropem unikalności można użyć podzapytania, które zwraca unikalne względem id_user rekordy a dopiero później, zwrócone przez nie rekordy posortować. Powyższe zapytanie wykona się i zwróci pewne rezultaty.

id id_user date
11 7 2008-10-01 00:00:00
9 5 2008-06-01 00:00:00
8 4 2008-05-01 00:00:00
5 3 2008-04-01 00:00:00
2 1 2008-01-01 00:00:00
4 2 2008-01-01 00:00:00

Niestety nie będą one do końca poprawne gdyż podzapytanie DISTINCT pozostawia pierwszy napotkany rekord zawierający unikalną wartość id_user. Zatem jeżeli dane nie są posortowane względem id_user i daty chronologicznie to uzyskamy wyniki nieprawidłowe. W naszym przypadku id_user=1 została zwrócona data=2008-01-01 gdyż jest ona bliżej początku niż rekord z datą=2008-05-01.

Rozwiązanie:

SELECT
 *
FROM
 (SELECT
  DISTINCT ON (sub2.id_user)
  sub2.*
 FROM
  (SELECT
  *
  FROM
  logs
  ORDER BY
  id_user ASC,
  date DESC
  ) AS sub2
) AS sub
ORDER BY
 sub.date DESC;

W podzapytaniu sub2 sortujemy dane po id_user i date malejąco tak aby każdy id_user na czele miał rekord z datą najpóźniejszą. Takie dane przekazujemy zapytaniu wcześniejszemu, które najpierw wyciąga rekordy unikalne względem kolumny id_user a następnie tak ograniczony zbiór sortuje względem kolumny date. Jako że dostarczyliśmy dane posortowane otrzymane rezultaty są zgodne z prawdą:

id id_user date
11 7 2008-10-01 00:00:00
10 5 2008-08-01 00:00:00
7 1 2008-05-01 00:00:00
8 4 2008-05-01 00:00:00
5 3 2008-04-01 00:00:00
4 2 2008-01-01 00:00:00

Zapytanie grupujące minimalnne wartości w grupie danych

Problem:
Chcemy wyświetlić miesięczne zestawienie liczby nowo zarejestrowanych
użytkowników mając jedynie daty ich logowań.

Posiadane dane:
Tabela z datami logowań użytkowników aplikacji w tabeli postaci:

	CREATE TABLE logs(
		id SERIAL PRIMARY KEY, -- unikalny klucz główny
		id_user INTEGER, -- klucz obcy tabeli użytkowników
		date TIMESTAMP -- data logowania
	);

Przykładowe rekordy:

INSERT INTO logs(id_user,date) VALUES(1,'2008-01-01');
INSERT INTO logs(id_user,date) VALUES(1,'2008-01-05');
INSERT INTO logs(id_user,date) VALUES(4,'2008-01-01');
INSERT INTO logs(id_user,date) VALUES(2,'2008-01-01');
INSERT INTO logs(id_user,date) VALUES(3,'2008-04-01');
INSERT INTO logs(id_user,date) VALUES(7,'2008-04-01');
INSERT INTO logs(id_user,date) VALUES(1,'2008-05-01');
INSERT INTO logs(id_user,date) VALUES(4,'2008-05-01');
INSERT INTO logs(id_user,date) VALUES(5,'2008-06-01');
INSERT INTO logs(id_user,date) VALUES(5,'2008-08-01');
INSERT INTO logs(id_user,date) VALUES(7,'2008-10-01');

Rozwiązanie:
Rejestracje można utożsamić z pierwszymi logowaniami, zatem:
Najpierw grupujemy dane według użytkownika i dla każdego id_user znajdujemy najwcześniejszą datę logowania. Następnie otrzymane dane grupujemy po roku i miesiącu.

Realizuje to podwójnie grupujące zapytanie:

SELECT 
	extract(year from date) || '-' || extract(month from date) AS month, 
	count(*) AS amount 
FROM 
	logs 
WHERE date IN (
	SELECT 
		min(date) 
	FROM 
		logs 
	GROUP BY 
		id_user 
) 
GROUP BY 
	extract(year from date) || '-' || extract(month from date)
ORDER BY
	amount DESC;

Można też ciut lepiej zoptymalizować zapytanie i operować bezpośrednio na wynikach zwróconych
przez podzapytanie:

	
SELECT 
	extract(year from sub.date) || '-' || extract(month from sub.date) AS month, 
	count(*) AS amount 
FROM 
 (
	SELECT 
		min(date) AS date
	FROM 
		logs 
	GROUP BY 
		id_user 
) AS sub
GROUP BY 
	extract(year from sub.date) || '-' || extract(month from sub.date)
ORDER BY
	amount DESC;	

W przypadku gdy zapytanie to będzie wykonywane często warto założyć index na kolumne z datą:

CREATE INDEX date_idx ON logs(date);

FirePHP – przyjazne debug’owanie aplikacji internetowych

Debugowanie to poważny problem programistów

Bez względu na to jakimi dobrymi programistami jesteśmy nigdy nie ustrzeżemy się błędów. To normalne, błędy popełnia każdy, różnica pomiędzy dobrym programistą a złym polega m. in. na szybkości wykrycia błędnego kodu i naprawienia go.

Mówiąc o błędnym kodzie nie mam na myśli jedynie błędów syntaktycznych, ale również błędów logicznych, które nie powodują widocznych error’ów a jedynie błędne działanie aplikacji. Takie błędy są dużo trudniejsze do wykrycia.

Aby wykryć błędny kod niezbędne jest zdebugowanie zmiennych, obiektów, zasobów, które wykorzystywane są w tworzonej przez nas aplikacji. Brzmi banalnie, jednak w rzeczywistości nie jest to takie łatwe gdyż:

  • po pierwsze trzeba wstawić w odpowiednie miejsca funkcje var_dump() lub print_r()
  • po drugie funkcje te nie wyświetlają przejrzyste i łatwe do zinterpretowania dane
  • po trzecie debug’owanie na ekran może spowodować błędy aplikacji, a debugowanie do pliku jest niewygodne w odczycie (szczególnie w przypadku aplikacji flash’owych lub AJAX’owych)
  • po czwarte zdarza się, że format zwracanych danych uniemożliwia swobodne dodawanie własnych danych do debugowania (np. XML, JSon).
  • po piąge po skończeniu debugowania trzeba usunąć wszystkie instrukcje debugujące

Rozwiązaniem problemu debugowania jest FirePHP

Dużo tych wad… całe szczęście jest na to rozwiązanie. FirePHP to darmowa, open source’owa biblioteka, która wraz z pluginem do Firebug’a idealnie sprawdza się w roli debugera.

FirePHP debuguje dane w konsoli Firebug’a, informacje do debugowania są umieszczone w specjalnych nagłówkach HTTP przez co ‚output’ aplikacji pozostaje w nienaruszonym stanie. Rewelacja prawda?

Instalacja firePHP

Wymagania FirePHP to PHP 5.2+, Firefox z pluginem Firebug.

  • Instalujemy plugina do firefox’a Firebug
  • Instalujemy plugina do Firebug’a FirePHP
  • Ściągamy źródła FirePHP, warto zauważyć, że na stronie dostępne są informacje, jak zintegrować bibliotekę z wieloma znanymi frameworkami (CakePHP, CodeIgniter, Drupal, Kohana, ExpressionEngine, PRADO, Symfony, TYPO3, Zend Framework).
  • Integrujemy FirePHP z naszą aplikacją
  • Odpalamy stronę aplikacji w Firefox z uruchomionymi plugin’ami Firebug i FirePHP
  • Klikamy na ikonę Firebug’a a następnie przechodzimy do konsoli. W konsoli powinny być zaprezentowane zdebugowane zmienne naszej aplikacji.
  • W przypadku problemów przydać się mogą: mini tutorial how to, forum dyskusyjne o FirePHP.

Przykład działania

Pod adresem http://blog.adiasz.pl/examples/firephp/ stworzyłem prosty skrypt AJAX’owy łączący się z bazą i wykonujący prościutkie operacje. Jest zintegrowany z FirePHP, zachęcam do testów. Naprawdę warto! (Oczywiście musicie najpierw zainstalować plugin FireBug i FirePHP). Wszystkie pliki wykorzystane w tym przykładzie dostępne są tutaj.

Przykład powinien zaprezentować coś w stylu:

Na koniec, bardzo ważna informacja: po opublikowaniu projektu musicie wyłączyć debugowanie FirePHP poprzez dyrektywę:

$fp = FirePHP::getInstance( true );
$fp->setEnabled ( false );

W przeciwnym razie każdy internauta posiadający zainstalowany ten plugin będzie miał dostęp do niebezpiecznych z punktu bezpieczeństwa danych. Najlepiej w konfigu aplikacji sterować to poprzez zmienną typu boolean $development = true/false. Samych instrukcji debugujących nie trzeba kasować gdyż nie wiadomo kiedy się jeszcze przydadzą.

ps. FirePHP dostępne jest także dla innych niż PHP języków programowania aplikacji webowych: ASP, Python, Ruby.

Darmowe narzędzia dla webmasterów: statystyki serwisu

Ostatnio w ramach optymalizacji czasu i automatyzacji wykonywanych przez zemnie zadań stworzyłem mini aplikację sprawdzającą statystyki moich serwisów w wyszukiwarkach.

Aktualnie sprawdzam: Google PR, Google link, Google site, Yahoo link, Yahoo site, MSN site. Monitoringu pozycji słów kluczowych na razie nie robiłem, gdyż jest wiele tego typu dobrych i darmowych sprawdzaczy na necie – więc szkoda czasu.

Aplikacja działa tak:
* skrypty sprawdzające statystyki wywoływane są z automatycznie z cron’a, dane zapisują w bazie
* po zalogowaniu prezentowana jest lista najnowszych statystyk
* generowane są dzienne wykresy poszczególnych statystyk serwisów

Prościutkie, teraz zamiast sprawdzać ręcznie tysiące parametrów wystarczy się zalogować do panelu. Wyniki zostaną zaprezentowane szybki i w przejrzysty sposób.

Dla szerokiego internetu udostępniłem wersję uproszczoną – możliwość sprawdzenia wyżej wymienionych statystyk dla podanego adresu: zapraszam na darmowe narzędzia dla webmasterów. Nic odkrywczego, ale może komuś się przyda.

Aplikacja została napisana we framework’u: Kohana, o którym postaram się napisać niedługo, a już teraz polecam się z nim zapoznać.

Błąd SmartyPDT w Eclipse 3.3.2 i PDT 1.0.3 z JRE 1.6

Niedawno update’owałem swoje IDE, i natknąłem się na mały zgrzyt w Eclipse. Okazało się, że najnowsza wersja 0.5.4 plugin’a do Smarty’ego (SmartyPDT) nie chce działać w środowisku Eclipse PDT z zainstalowanym JRE 1.6.

Błąd

Otwarcie pliku *.tpl w domyślnym edytorze smarty’iego dawało błąd:

java.lang.IllegalAccessError?: tried to access field org.eclipse.php.internal.ui.editor.PHPStructuredEditor.isExternal from class org.eclipse.php.smarty.ui.editor.SmartyStructuredEditor?
    at org.eclipse.php.smarty.ui.editor.SmartyStructuredEditor?.doSetInput(SmartyStructuredEditor?.java:42) at org.eclipse.ui.texteditor.AbstractTextEditor?$19.run(AbstractTextEditor?.java:3003) at org.eclipse.jface.operation.ModalContext?.runInCurrentThread(ModalContext?.java:369) at 
etc...

Błąd w całości można obejrzeć tutaj. Po małym dochodzeniu okazało się, że wersja SmartyPDT 0.5.4 działa w co najwyżej 1.5 The J2SE Runtime Environment (JRE), natomiast na mojej maszynie zainstalowane jest najnowsze JRE 1.6.

Rozwiązanie

Aby SmartyPDT działało poprawnie trzeba ściągnąć nieoficjalną wersję 0.5.5, która dostępna jet tutaj. Następnie wgrać do katalogu eclipse, przejść Help->Software Updates->Manage Configuration i dać ‚disable’ na wersji 0.5.4 i ‚enable’ na wersji 0.5.5

Po restarcie Eclipse wszystko działa poprawnie.

Refleksja

Ciekawe dlaczego na stronie SmartyPDT nie ma słowa o tej niezgodności, oraz dlaczego w download’zie nie ma najnowszej wersji 0.5.5?