Za każdym razem gdy przychodzi mi skorzystać z dobrodziejstwa jakim są wyrażenia regularne (które swoją drogą mogłyby się dorobić jakiegoś ogólnie uznawanego standardu), sięgam po gotowe i sprawdzone wzorce. Poniżej umieściłem kilka najczęściej używanych przeze mnie wyrażeń regularnych wraz z przykładowym kodem w PHP.

Adres email
Walidacja adresu email jest często spotykanym przykładem użycia wyrażeń regularnych. Adres email składa się z 3 podstawowych części:

• nazwy użytkownika - za sprawdzenie tego elementu odpowiada ([0-9a-zA-Z]([-_.\w]*[0-9a-zA-Z_])*
• symbolu @
• oraz nazwy domeny - za sprawdzenie tego elementu odpowiada (([0-9a-zA-Z])+([-\w]*[0-9a-zA-Z])*\.)+[a-zA-Z]{2,9})

Całość daje nam razem uproszczony adres email, którego poprawność możemy sprawdzić używając poniższego kodu:

$test_string = "przykladowy@email.tutaj.pl";
if (preg_match('/^([0-9a-zA-Z]([-_.\w]*[0-9a-zA-Z_])*@(([0-9a-zA-Z])+([-\w]*[0-9a-zA-Z])*\.)+[a-zA-Z]{2,9})$/', $test_string))
{
	echo 'OK';
}
else
{
	echo 'Failed';
}

Adres URL
Czyli format adresowania zasobów internetowych najczęściej kojarzony z adresami stron www. Adres ten możemy rozbić na następujące części:

• rodzaj protokołu - (http|https|file)
• opcjonalna nazwa użytkownika i hasło - (\w*:\w*@)?
• nazwa hosta - [-\w.]+
• opcjonalny numer portu - (:\d+)?
• ścieżka dostępu - (/([\w/_.]*
• zapytanie - (\?\S+)?

Poprawność URLa możemy sprawdza następujący kawałek kodu:

$test_string = "http://login:haslo@www.rogozinski.net:80/admin/test.php?action=edit&id=166";
if (preg_match("/^(http|https|file):\/\/(\w*:\w*@)?[-\w.]+(:\d+)?(\/([\w\-\.\/]*(\?\S+)?)?)?$/", $test_string))
{
	echo 'OK';
}
else
{
	echo 'Failed';
}

Adres IP

W wydaniu IPv4, są to cztery liczby od 0 do 255 oddzielone kropkami.

$test_string = "255.255.255.0";
if preg_match('/^(?:25[0-5]|2[0-4]\d|1\d\d|[1-9]\d|\d)(?:[.](?:25[0-5]|2[0-4]\d|1\d\d|[1-9]\d|\d)){3}$/', $test_string))
{
	echo 'OK';
}
else
{
	echo 'Failed';
}

Data i godzina (w formacie 24H)

$string = '2007-02-15 03:15';
if (preg_match('/^([0-9]{4}-[0-9]{2}-[0-9]{2})\s((0{0,1}[0-9])|(1[0-9])|([2][0-4])):([0-5][0-9])$/', $string))
{
	echo 'OK';
}
else
{
	echo 'Failed';
}

Kod pocztowy

$test_string = '05-324';
if (preg_match('/^[0-9]{2}[-]([0-9]{3})?$/', $test_string))
{
	echo 'OK';
}
else
{
	echo 'Failed';
}

Wszystkie przykłady wyświetlają napis ‘OK’ w razie prawidłowego rozpoznania wzorca i ‘Failed’ w razie porażki.

Warto zobaczyć:

• Wprowadzenie do PHP Regex

Na memcached natknęliśmy się podczas projektowania systemu wielojęzyczności (i18n) jednego z naszych serwisów. Problemem była kwestia przechowywania tłumaczeń tekstów. Pomysłów było kilka:

• tłumaczenia przechowywane w plikach PHP, odpowiedni plik ze stałymi będzie includowany podczas obsługi żądania strony,
• tłumaczenia przechowywane w plikach XML, pliki będą doczytywane w miarę potrzeby,
• tłumaczenia przechowywane w bazie danych, i na bieżąco wczytywane.

Wszystkie te podejścia mają jednak słaby punkt, otóż za każdym żądaniem strony, tłumaczenia muszą być wczytywane od nowa. Faktem jest, że wszystkie trzy metody zawierają w sobie pewien rodzaj cache’owania (wczytywane pliki są cache’owane przez system operacyjny, zapytania bazodanowe cache’owane są przez bazę danych), ale tak na prawdę żaden z nich nie oferuje optymalnego rozwiązania. Najgorszym spośród wyżej wymienionych rozwiązań jest chyba czytanie tłumaczeń z plików XML. Wyobraźmy sobie, że za każdym razem gdy skrypt napotyka napis, musi wczytać odpowiedni plik i przeparsować XML w celu znalezienia tłumaczenia. Dodajmy do tego średnio 100 użytkowników aktualnie korzystających z aplikacji webowej i mamy murowaną porażkę. Można oczywiście spróbować cache’ować napisy na czas żądania strony, ale trzeba wziąć pod uwagę, że tłumaczenia raz wczytane, nie będą się często zmieniać. Większość z nich jest również wspólna dla wszystkich użytkowników. Tutaj do akcji spokojnie można zaprząc memcached.

Den ganzen Beitrag lesen…

Kilka dni temu, podczas projektowania edytora tekstu zauważyłem ciekawe zjawisko dotyczące przesyłania danych POSTem i ich odbioru w PHP. Zjawisko to, a w zasadzie błąd, powoduje ucięcie pojedynczego znaku nowej linii podczas przesyłania formularza, pod warunkiem, że jest to pierwszy znak w przesyłanym tekście. Problem ten dotyczy tekstu edytowanego za pomocą html’owego textarea i występuje w PHP 4 i 5 (sprawdzałem na PHP 4.4.6 oraz PHP 5.2.2). Dodam, że efekt ten nie występuje gdy formularz jest przesyłany metodą GET.

Den ganzen Beitrag lesen…

Ostatnio coraz częściej zastanawiam się co się stało ze wzorcami projektowymi, programowaniem obiektowym, dokumentacją kodu źródłowego… czy ktoś jeszcze tego używa? czy może to już zamierzchła przeszłość? Wystarczy się trochę rozejrzeć… i nawet daleko nie trzeba szukać.

Niedawno miałem przyjemność wprowadzenia kilku zmian dotyczących funkcjonowania FlySpray’a (dla nieobytych, jest to taki program do obsługi zgłoszeń, np. raportowania błędów). Okazuje się, że programiści FlySpray uznali, że komentarze w kodzie źródłowym, czy też jakiś rodzaj manuala dla developerów jest zupełnie niepotrzebny. Nie wiem w jaki sposób dalej rozwijają już i tak dosyć skomplikowany projekt. Chyba po prostu piszą go nieprzerwanie od samego początku.

Dalej szarpnęliśmy się na próbę zainstalowania pligga (taki serwis pozwalający na postawienie swojego digga). Niestety, ale pligg sam z siebie, po zainstalowaniu, namiętnie wypluwał notice’y i warningi. Postanowiliśmy więc, pogrzebać trochę w kodzie, a nuż okaże się, że to jakiś mały problem i będziemy mogli spokojnie cieszyć się naszym własnym wykopem To co zobaczyliśmy totalnie nas zaskoczyło (no może nie wszystkich - ja już powoli się przyzwyczajam ;)). Wolna amerykanka to mało powiedziane, kod pligga to po prostu ’starocerkiewny’ (mieszanka kodu php, html, css i javascript w jednym pliku :D). Miłym dodatkiem do tych atrakcji jest również brak dokumentacji…

Na koniec zostawiłem sobie ostatnią nowinkę ze świata wielkich społeczności. Niedawno, w cudowny sposób, wypłynął na wierzch kod jednego z największych, społecznościowych serwisów, mowa oczywiście o Facebook. Co się okazało? Facebook również napisany jest w starocerkiewnym. Ech…

O ile można próbować wytłumaczyć styl programistów Facebook’a, którzy nie planowali upubliczniania swojego kodu, o tyle dziwi mnie postępowanie programistów dwóch pozostałych aplikacji. Przecież projekty open source są z zasady otwarte i każda osoba może przeanalizować kod źródłowy. Wydaje mi się, że jest to wystarczający powód aby utrzymywać w miarę porządny styl programowania i znośną dokumentację. Jeśli to za mało, można również dodać, że porządnie udokumentowane i prawidłowo napisane aplikacje pozwalają na zdecydowanie łatwiejsze rozwijanie i mniejsze koszty utrzymania.

Zobaczymy co będzie dalej, z niecierpliwością czekam na kolejną wersję FlySpray’a

Poszukuję programistów aplikacji internetowych (technologie: PHP / ASP / JAVA). Więcej informacji na stronie Praca lub na stronie firmy Posterus.

Pracując nad obsługą dat w PHP napotkałem problem, który jest bardzo często niezauważany lub pomijany. Otóż timestamp (czyli liczba sekund, która upłynęła od dnia 1 stycznia 1970) jest w PHP przechowywany i przetwarzany jako integer. Cóż z tego? Otóż ogranicza to jego reprezentację do 32 bitów, a mówiąc wprost najbardziej odległą datą jaką można zapisać w takim timestampie jest 19 stycznia 2038. Co jeśli interesuje mnie praca z późniejszymi datami? Krótko mówiąc lipa, timestamp w PHP nie przewiduje takiej możliwości. Byćmoże zostanie to rozwiązane w kolejnej wersji PHP.

Den ganzen Beitrag lesen…